January 2004 - council - lists.icann.org

"Approval Process for gTLD Service Changes": Constitiency statements
by GNSO SECRETARIAT Feb. 3, 2004

Feb. 3, 2004

[To:council[at]gnso.icann.org] Please find the Commercial and Business Users constituency, Intellectual Property Interests constituency, Non Commercial Users constituency and the At Large Advisory Committee statements on "Procedure for use by ICANN in considering requests for consent and related contractual amendments to allow changes in the architecture or operation of a gTLD registry." or "Approval Process for gTLD Service Changes" at: http://gnso.icann.org/issues/registry-services/constituency-statements.shtml Commercial and Business Users constituency statement: http://gnso.icann.org/issues/registry-services/cbuc-statement.shtml Intellectual Property Interests constituency statement: http://gnso.icann.org/issues/registry-services/ipc-statement.shtml Non Commercial Users constituency statement: http://gnso.icann.org/mailing-lists/archives/council/msg00372.html At Large Advisory Committee statement: http://gnso.icann.org/issues/registry-services/alac-statement.shtml GNSO Secretariat

2 1

GNSO Council teleconf. January 22/23,2004, MP3 recording
by GNSO SECRETARIAT Jan. 22, 2004

Jan. 22, 2004

[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 January 22/23, 2004 at: http://gnso-audio.icann.org/GNSO-Council.20040122.MP3 Happy listening! GNSO Secretariat gnso.secretariat[at]gnso.icann.org

1 0

Status of registrar constituency statement on the approval process for new gtld services
by Bruce Tonkin Jan. 22, 2004

Jan. 22, 2004

Hello All, I have attached a current draft of the registrars constituency statement on new gtld services. The draft has been endorsed by 5 registrars and has been submitted for voting by the whole constituency. A copy of the draft is attached in Microsoft word format, and a plain text version is included below. Regards, Bruce Tonkin DRAFT3 21 Jan 04 Registrar Constituency Statement This registrar constituency statement relates to the GNSO Policy Development Process on a Procedure for use by ICANN in considering requests for consent and related contractual amendments to allow changes in the architecture or operation of a gTLD registry, in accordance with Section 7(d) (1) of the GNSO Policy Development Process. (1) A vote on this statement was held on <insert date>, with the following result <insert results>. (2) The registrar constituency carried out discussions on the topic via its public mailing list at: http://gnso.icann.org/mailing-lists/archives/registrars/ and via the following meetings or teleconferences: - Registrars constituency meeting in Carthage, Tunisia - Tuesday 28 Oct 2003 - Teleconference - 11 Dec 2003 - Following the teleconference a draft statement was submitted to the registrars mailing list on 17 Dec 2003 (see http://www.gnso.icann.org/mailing-lists/archives/registrars/msg01039.htm l ) - A first draft of a constituency statement was submitted to the registrars mailing list on 9 Jan 2004 (see http://www.gnso.icann.org/mailing-lists/archives/registrars/msg01122.htm l ) - A second draft of a constituency statement was submitted to the registrars mailing list on 16 Jan 2004 (see http://www.gnso.icann.org/mailing-lists/archives/registrars/msg01169.htm l ) (3) Analysis of how the registrars constituency is affected by the issue Changes in the architecture or operation of a gTLD registry can affect members of the registrars constituency in the following ways: - a change may affect the commercial viability of many registrars with the result of an overall reduction in the level of competition and consumer choice - a change may affect a registrar's customers (which may be individuals, organisations, or intermediaries that provide domain name services), which often results in higher customer support costs, particularly in regard to sudden unexpected changes in operation - a change may require changes in a registrar's business processes, which typically requires additional software development work and thus additional expense. Additional software development work that does not either reduce a registrar's costs, or increase a registrar's revenue will ultimately result in higher prices for its customers. As a separate issue, the registrars' constituency recommends that ICANN review its funding model, and consider how to levy its fees more broadly across different registry services rather than the present model which is based on the number of domains under management. Addressing the terms of reference for the policy development process, the registrars' constituency notes the purpose of the policy development is to create a policy concerning the essential characteristics of the process by which ICANN considers registry operator or sponsor requests for consent or related contractual amendments to allow changes in the architecture or operation of a gtld registry. The registrar constituency addresses each of the tasks of the PDP below. (1) Develop guidelines for when approval is required to make a change based on the existing registry agreements. It would assist the industry to have a simple set of guidelines for when it is necessary for a registry operator (particularly unsponsored) to seek approval from ICANN. The following is a simplified list of areas where approval is required based on the unsponsored registry agreement. (a) Changes to reports provided to ICANN (b) Changes to schedule, content, format and procedures for data escrow (c) Changes to the specification for the publication of data or changes to query based access or bulk access concerning domain name and name server registrations (ie WHOIS service) (d) Changes to the Registry-Registrar agreement (e) Material changes and additions in the functional specifications for "Registry Services" (f) Changes in the performance specifications for "Registry Services" (g) Changes to the zone file access agreement (h) Changes in the maximum price for "Registry Services" (i) Changes in the Registry Operator's Code of Conduct (j) Changes in the registration of domain names for a registry operator's own use With regard to unsponsored gtlds, the registrars constituency notes that although portions of the policy-development authority for each sTLD are delegated to the designated sTLD sponsor, there are some situations in which an sTLD's sponsor will request amendments to, or approvals under, the sponsorship agreement it has with ICANN. Although approval and amendment requests are much more common in the case of unsponsored TLDs than for sTLDs, the overall goals (e.g., predictability, timeliness, transparency) of the procedures for handling gTLD and sTLD requests are similar, even though there are differences in the provisions of the underlying agreements that must be observed. The areas of particular concern for registrars relate to changes in the Registry-Registrar agreement and changes in the performance, specification and prices of "Registry Services". The registrars constituency recommends that ICANN adopt a consistent definition of registry services to guide the industry in determining when ICANN approval is required. The registrars constituency favours the definition used in the .biz agreement ie "Registry Services" means services provided as an integral part of the operation of the Registry TLD, including all subdomains in which Registered Names are registered. In determining whether a service is integral to the operation of the Registry TLD, consideration will be given to the extent to which the Registry Operator has been materially advantaged in providing the service by its designation as such under this Agreement. (this consideration should be added to any registry agreements that do not currently have it.) The development of technology, expertise, systems, efficient operations, reputation (including identification as Registry Operator), financial strength, or relationships with registrars and third parties shall not be deemed an advantage arising from the designation. Registry Services include: - receipt of data concerning registration of domain names and nameservers from registrars, - provision to registrars of status information relating to the Registry TLD, - dissemination of TLD zone files, - operation of the Registry TLD zone servers, - dissemination of contact and other information concerning domain-name and nameserver registrations in the Registry TLD, and - such other services required by ICANN. Registry Services shall not include the provision of nameservice for a domain used by a single entity under a Registered Name registered through an ICANN-Accredited Registrar. (2) Develop a check list of issues to consider when approving a change ICANN should refer to its mission and its core values taken from the ICANN bylaws in formulating the check list of issues to consider when approving a change. Mission: to coordinate, at the overall level, the global Internet's systems of unique identifiers, and in particular to ensure the stable and secure operation of the Internet's unique identifier systems. Three of the core values of particular relevance are: Core value 1: Preserving and enhancing the operational stability, reliability, security, and global interoperability of the Internet. Core value 5: Where feasible and appropriate, depending on market mechanisms to promote and sustain a competitive environment. Core value 6: Introducing and promoting competition in the registration of domain names where practicable and beneficial in the public interest. The challenge for ICANN is allowing registry operators to innovate and evolve their services while ensuring that the operational stability, reliability, security, interoperability of the Internet is preserved, and ensuring that there is a healthy competitive market in the provision of domain name registration services by registrars. When approving a change ICANN must determine whether: (a) The change requires ICANN approval. Where there is a change related to the functional, performance or prices of a service, ICANN will need to first determine if the service fits under the definition of "Registry Service". (b) Whether to use a fast track or a more time-consuming approval process. In general changes that do not relate to the registry-registrar agreement or Registry Services could be subject to the fast track process. (c) The change is likely to affect operational stability, reliability, security and global inter-operability of the Internet. The fact that an effect is likely should not be a bar to the new service; rather these factors and a registry's ability to minimize risks must be weighed in considering whether, and under what conditions, to approve a service. This should be fairly straight forward for most of the proposed changes, however a proposed change in the functional and performance specifications of a "Registry Service" should include impartial external advice from one or more technical experts. Where there is a possibility of an issue associated with operational stability, reliability, security and global inter-operability of the Internet, ICANN staff should use a more comprehensive approval process. The terms "operational stability", "reliability", "security" and "global interoperability" should be more clearly defined in the context of domain name registries, with examples of changes that could cause problems. The ICANN Security and Stability Advisory Committee could assist in providing clarification of these terms. The following is some suggestions for clarifying these terms: a. Operational stability - The three main components of registry operation relate to the provisioning system whereby registrars provide instructions to the registry via the registry-registrar protocol to register and maintain domain name records, the DNS nameservice provided to Internet users via the DNS protocol, and the domain name holder information provided to Itnernt users via an interactive web page and the port 43 Whois protocol. Sudden changes to the behaviour of any of these systems can impact the stability of applications that make use of these systems. For example a change to the registry-registrar protocol could result in accidental deletion of domain name records, or incorrect configuration of nameserver information associated with a domain name record. A change in the behaviour of the DNS nameservice such as the introduction of wildcard behaviour, may result in failure of some applications that rely on that behaviour. The general approaches to maintaining operational stability are : i. ensure that changes are backward compatible, ii. ensure that the old and new environments are supported in parallel for a suitable period iii. and ensure that sufficient notice period is provided. The length of time for operating parallel environments or providing a notice period should be proportional to the significance of the change. A registry operator should also provide a test environment prior to putting a change into production to ensure that users can check that there software will continue to operate. This should apply to the provisioning environment, the DNS nameserver environment, and the WHOIS service. b. Reliability - reliability typically relates to the availability of the registry operator systems, but it also related to the reliability of the applications that use the service. For example a change in the behaviour of the DNS nameservice may reduce the reliability of other important applications such as email that use the Internet. c. Security - again security relates both to the security of the information maintained by the registry operator, as well as the security of applications that use the registry systems. For example, digital certificates may be used based on the information available in the WHOIS service. If this information is either no longer available, or is incorrect, then it can affect the security of applications that use the digital certificate. d. Global Interoperability - where possible Internet user application should be able to work with any of the gtld registry systems. For example, all the gtld registries should aim to use the same core registry-registrar protocols, WHOIS and DNS protocols. A recent innovation that requires coordination is the introduction of internationalised domain names. The IETF has recently converged on a standard for encoding characters used in different languages into ASCII text (Punycode). Before giving permission to change a core protocol or data format, ICANN should seek to facilitate cooperation amongst registries and registrars to agree on a common protocol or data format. (d) The change is likely to reduce the competition in the registration of domain names. This is often a controversial issue because often changes will affect the business models of one or more registrars, or their intermediaries. For example, a change in the way a registry operator allocates domain names that have been deleted will directly affect those registrars that rely on registrations of previously registered names as their main source of revenue. Where ICANN staff believe that a registrar business model could be affected by a change in the registry systems, ICANN should seek impartial advice from a competition expert with a strong understanding of the domain name industry structure. Where there is a possibility of an issue associated with the overall competition (as distinct from an individual competitor) in the domain name industry, ICANN staff should use a more comprehensive approval process. The issue should be considered from the point of view of the "long term" interests of end users. In general the long term interests are best serviced by a healthy competitive industry amongst domain name registrars because every registry is a natural monopoly in a particular TLD. A registry has a substantial degree of market power for registrants within that tld, as the switching costs for a registrant are often high to move to another tld. Therefore, vigorous competition among registrars is the only way that the market can be certain of providing the best prices and services. Registrars need to be able to differentiate their product offerings and add value, otherwise the value of a domain name will mostly reside with the registry operator and there will be little incentive to operate as a registrar. This will result in a return to a single provider for a particular domain name space. Where a new "Registry Service" is proposed, ICANN should consider whether the same service can be effectively provided by registrars or their intermediaries. For example, if a registry operator chose to limit the nameservers available to be associated with a domain name to only nameservers operated by the registry operator this would constrain competition. Another example could be the provision of an email service that was only available from the registry operator (e.g name@gtldname). Where possible registrars should have access to unbundled service offerings. If registrars cannot provide the service effectively, ICANN staff should not deny the registry operator the right to launch the service, although they may place certain conditions on the service in order to safeguard competitive offerings by the registrar sector. If registrars can effectively provide the service, ICANN staff should not allow the registry operator to provide the service as a bundled product, at a price point that takes advantage of the registry operator's monopoly position, or in a manner that claims a better offer by the registry operator by virtue of being the registry operator. (3) Develop a process and timeline for responding to a request including "quick-check" phase, and more comprehensive phase. The essential characteristics of a process to consider registry operator or sponsor requests for consent or related contractual amendments to allow changes in the architecture or operation of a gTLD registry are the following: (a) Confirm that the change needs ICANN approval. This should include legal and/or technical advice in the case of determining with a service is a "Registry Service" (b) Determine whether the change is likely to likely to affect operational stability, reliability, security and global inter-operability of the Internet, or competition in the registration of domain names. This should include impartial technical expert advice or competition expert advice. If there is no possibility of any issue, then proceed to approve within 14 days. If there is clearly a problem than deny approval within 14 days. This is the fast track process. (c) If there is uncertainty about the impact of the change on operational stability, reliability, security and global inter-operability of the Internet, or competition in the registration of domains names, notify the applicant within 14 days that a more extensive public process will be used and allow the option for the applicant to withdraw the request. (d) The more comprehensive process should consist of a 30 day consultation period consisting of a. collecting public comments facilitated by the ICANN Manager of Public Participation b. facilitating briefings for major affected stakeholders (e.g registrars when a change is proposed to provisioning system, or ISPs if a change is proposed to the DNS nameservice) c. collecting constituency statements from each GNSO constituency d. collecting statements from the ALAC, GAC, SECSAC as appropriate (e) At the end of the 30 day consultation period, ICANN staff would have 14 days to prepare a report and provide a decision to the applicant. In cases where the change is rejected, the ICANN report should provide guidance on what alterations to the proposal could be made to allow ICANN to approve the change. For example ICANN staff may recommend safeguards to preserve competition in the registration of domain names, or safeguards such as longer notice periods to preserve the operational stability of the Internet. (4) Develop a process and timeline for an appeals procedure for use by registry operators Access to the appeals procedure should be available to all members of the ICANN community rather than just registry operators. There is an existing procedure for reconsideration under section 2 of Article IV of the ICANN bylaws which is open to any person or entity that is materially affected by an action by ICANN. The timeline for the procedure in the ICANN bylaws is: (a) A request for reconsideration must be submitted within 30 days of the decisions (b) The reconsideration committee has 30 days to announce whether it will proceed to consider the request (c) The reconsideration committee has a total of 90 days to make a final recommendation.

1 0

Hi
by Elisabeth.Porteneuve＠cetp.ipsl.fr Jan. 21, 2004

Jan. 21, 2004

Test =) sxeaovyr -- Test, yep.

1 0

Preliminary ALAC remarks on new registry services.
by Thomas Roessler Jan. 17, 2004

Jan. 17, 2004

Hello, please find below some preliminary remarks from the ALAC on the ongoing "new registry services" PDP. We are also soliciting public comments on these remarks, and will follow up with information about any input we receive about this. Regards, -- Thomas Roessler <roessler(a)does-not-exist.org> At-Large Advisory Committee: http://alac.info/ ALAC Remarks on a Procedure for use by ICANN in considering requests for consent and related contractual amendments to allow changes in the architecture or operation of a gTLD registry. Introduction In the present document, we will focus on substantive criteria to be used by ICANN in evaluating requests to review proposed changes to the architecture or operation of a gTLD registry. We are, however, not stating any opinion about the kinds of requests that ICANN currently has the authority (or obligation) to consider. Procedural remarks On the procedural side, we generally believe in accountable, transparent and objective processes that ensure that policy is applied in a neutral manner. Where it is not possible to stick to these principles, though, we prefer well-documented mechanisms for stakeholder participation over undocumented back-room deals. If the process has to be political, it should be openly so. If some groups of stakeholders are going to be involved,In particular, the process should provide opportunities for all such groups relevant parties (including GNSO constituencies and Advisory Committees) to get involved, and should, in particular, incorporate opportunities for meaningful and early public comment. Substantive remarks Burden of proof; principles. --- As a fundamental principle, what some call the "first law of the Internet" should be applied to proposed registry changes: Any privately beneficial activity should be allowed unless it is shown to be publicly detrimental; those who want to forbid an activity bear the burden of proving public harm. In this scheme, bad ideas are not forbidden, but tried, and doomed to - maybe unexpected - failure. Whether a proposed change is "good" or "bad", or wanted by the Internet community, is not decided by some body a priori, but measured by market success - or failure: Where the community's interest is measurable in market terms, "regulatory" decisions can and should be avoided. Conversely, where market feedback cannot accurately define the community's interest because of the absence of a competitive market, or because of the imposition of spillover costs, the community's interest must be defined in another way. For example, imagine that a registry imposes a change in behavior affecting all incumbent registrants. Those registrants would have to incur high switching costs in order to change to another TLD; that fact distorts the market's response to the registry change. For another example, imagine that a change in the DNS responses returned by the registry leads to a change of software behavior for users who have not changed their software or configuration. Since users, in their roles as consumers of DNS data, cannot control this change through their purchasing decisions, they cannot provide market feedback. And they are stuck with the changed software behavior, since reconfiguring or modifying their client software will likely be unacceptably costly to them. In such situations, it should be the registry's burden to prove that no harm is caused by the proposed change. Whether or not market feedback can provide an accurate barometer of the desirability of the proposed change should be a crucial test within the intial quick-look analysis of any proposed change that ICANN assesses. Where a proposed change fails this test, it should be the registry's burden to prove that no harm is caused by the proposed change. Harm. --- We focus on three areas of significant harm that can be caused by changes to registry architecture or operations: Changes that affect the network's openness for innovation; changes that cause cost at the edges but benefits for the registry; and changes that enable registries to leverage their monopoly position into different markets where they can then compete unfairly. One of the key elements in keeping the network open for innovation is the protocol neutrality of the naming and addressing framework: When new protocols are introduced, the DNS protocol in general needs no change - it is flexible enough to provide naming services for new protocols. The introduction of HTTP, for instance, required no change to the DNS. It is extremely rare that the DNS has special provisions for specific protocols, the most prominent example being MX records which enable e-mail service for domain names which are not mapped to IP addresses themselves. These special provisions, though, are designed so they do not interfere with the behavior of the DNS protocol as used by other protocols; they can be introduced without causing harm to (in fact, without even being noticed by) Internet users at large, and they do not harm the Internet's openness. Harm is caused, though, when registries introduce new services and change DNS behavior in a way which caters to the needs of some specific protocol, but makes the DNS less useful for other existing protocols, and for future innovation. As one committee member put it, the protocol-neutral, end-to-end net - of which the protocol-neutral DNS is a key ingredient - offers a neutral background for line drawing, oil painting, and collage. Sure a grid on the blank canvas would help those making mechanical drawings at the right scale, but it's just noise to the rest, who now need to paint an extra layer to cover it up. A more general characteristic of harmful registry changes is to cause cost at the network's edge, while benefitting the registry, by , e.g., breaking existing expectations, specifications, or implementations. Effectively, such scenarios would mean that registries attempt to profit without bearing the actual cost of rolling out a change; the economics here are analogous to those of environmental pollution. Just as environmental pollution can be completely rational behavior (unless penalized by law or liability), it is rational for registries to attempt to profit, while shifting the cost to others. ICANN should strive to prevent this from happening. Registries should not be allowed to leverage their monopoly position for wholesale domain name registrations into other markets. Such leverage can occur in many ways, and it is crucial that ICANN engage in thorough and thoughtful analysis of these questions. To give just one example, a registry replacing error responses by pointers to a registry-operated service is using its monopoly to override end users' choice about how they want errors to be handled. Error handling, as implemented in client software, is no longer the object of competition with this change implemented. Additionally, the registry would invade the pay-per-click search engine market through a route available only to the registry. At t he same time, routes into that market which are based on end-user decisions (browser plugins, for instance), are disabled. Also, registries should not be permitted to establish new monopolies where this can be avoided. Instead, preference should, whereever possible, be given to designs in which similar services can be provided by multiple parties; designs which permit market-based pricing of services should be preferred over designs that lead to monopoly pricing.

1 1

Guidelines for data collection requests relating to task force work
by Bruce Tonkin Jan. 16, 2004

Jan. 16, 2004

Hello Brian, Jeff, and Jordyn, As discussed today I suggest the following approach with respect to addressing requests for data collection. (1) Role of Advisory Committees The Advisory Committees including the Governmental Advisory Committee, Security and Stability Advisory Committee, Root Server Advisory Committee, At-Large Advisory Committee are generally expected to review proposed policy changes that affect their areas of expertise as part of the public comment processes built into the GNSO policy Development process. These committees would not generally participate directly in GNSO policy development, although it is recognised that members of the At-Large Advisory Committee have been very helpful in supporting policy development on behalf of individual Internet users. In the case of WHOIS, some of these Advisory Committees are conducting their own activities with respect to considering WHOIS issues, and it is important, through the liaisons the GNSO has with each of these committees, that the committees are kept informed of the work in the GNSO. (2) Requests for data A highlight of the recent work on WHOIS policy development has been the need to collect further data. A task force should define what data/information needs to be collected, and then use the personal networks of the task force members and liaisons to ask individuals or organisations to respond to the data request within the timeframe allocated by the task force. The ICANN Staff manager can also advise the relevant Advisory Committee liaisons, the ccNSO and the ASO that such information is being sought. The relevant liaison can elect to pass on such requests as appropriate to their members, and their members should respond directly to the task force (rather than requiring a formal advisory committee or supporting organisation response). Given that there are several task forces working on WHOIS, I recommend that the ICANN Staff Manager collate the various data collection requests, and inform the Advisory Committees and the ccNSO of the information being sought. Advisory Committees, ccNSO, or other groups (e.g CENTR) that are in the process of doing their own data collection related to WHOIS, may be able to incorporate some of the questions into their own surveys. Each task force should ensure that it does not become reliant on the data collection plans of other organisations (which may occur over much longer time scales). While questions addressed directly to individuals or organisation is a useful source of information, the ICANN Staff Manager and task force members should also seek sources of information that has already been collected and analysed, potentially over a prolonged period of time. Regards, Bruce Tonkin

1 0

RE: [council] NCUC statement on Approval Process for Registry Services
by Cade,Marilyn S - LGCRP Jan. 14, 2004

Jan. 14, 2004

Actually, I might just explain on Philip's initial comment. The "typical motivations" of business uses are very broad, and first and foremost, involves using the names that we, as business users, register to communicate with customers, market products, provide customer service, provide actual products to users, manage our own internal communications, etc. etc. :-) One motivation of some business users, from time to time, is to take defensive registration, when compelled to do so, to ensure against customer/user confusion and misleading communications, trademark infringement, protect against misuse of a domain name that is similar to a service or trademark use, etc. Bad faith is one critical concern of business users. But their interests are varied, just as their business models, strategy, and "reach" and products/services are. :-) As to ICANN's role in ensuring a stable and predictable environment in the Internet's technical functioning, we may have differences about how to achieve that, or the exact scope, but it is a primary concern to business users. Marilyn S. Cade AT&T Law & Government Affairs 1120 20th Street, NW, Suite 1000N Washington, DC 20036 202-457-2106v 281-664-9731 e-fax 202-360-1196 c mcade(a)att.com -----Original Message----- From: Philip Sheppard [mailto:philip.sheppard@aim.be] Sent: Wednesday, January 14, 2004 3:26 AM To: council(a)gnso.icann.org Subject: [council] NCUC statement on Approval Process for Registry Services Marc, while I think there is much to commend in the NCUC statement on the registry services I feel impelled to make one remark to this part of your statement: " we note that ICANN invested most of its effort in protecting trademarks ... interests, and has shown very little interest in protecting consumers and users". ICANN's UDRP is all about protecting consumers and users. The typical motivation for a brand owner to seek ownership of a domain name is to prevent the bad faith use of the domain name. Bad faith use includes consumer fraud and deception. There maybe individual cases where other motivations are apparent but please do note that the fundamental reason for trademarks at all is as a guarantee of origin - and that is a consumer as well as a brand-owner benefit. Philip

2 1

Re: [council] NCUC statement on Approval Process for Registry Services
by Jisuk Woo Jan. 14, 2004

Jan. 14, 2004

> 받는사람 : council(a)gnso.icann.org > 참조 : > 보낸날짜: 2004/01/14 17:26 > 제목: [council] NCUC statement on Approval Process for Registry Services > 보낸사람 : Philip Sheppard <philip.sheppard(a)aim.be> > > Marc, > while I think there is much to commend in the NCUC statement on the registry services I feel impelled to make one remark to this part of your statement: > > " we note that ICANN invested most of its effort in protecting trademarks ... interests, and has shown very little interest in protecting consumers and users". > > ICANN's UDRP is all about protecting consumers and users. Really? It seems that Marc and Philip have shown very different opinions on what UDRP is all about. I feel rather compelled to say that you might want to look at the simple statistics of UDRP decisions (in about 80% of proceedings trademark owners have won and domain names were transferred from the original registrants), let alone the many ways in which the UDRP policy and rules are established to result in disadvantaging the registrants, i.e., the respondents. I do not mean to start arguments about UDRP here, as there are certainly different opinions regarding its role and implications. But I would like to mention that I strongly support the specific statement in the NCUC statement on the registry serives: " we note that ICANN invested most of its effort in protecting trademarks ... interests, and has shown very little interest in protecting consumers and users", and I hope that the NCUC's position supporting stronger user protection be understood and respected. Jisuk Woo >The typical motivation for a brand owner to seek ownership of a domain name is to prevent the bad faith use of the domain name. Bad faith use includes consumer fraud and deception. There maybe individual cases where other motivations are apparent but please do note that the fundamental reason for trademarks at all is as a guarantee of origin - and that is a consumer as well as a brand-owner benefit. > > Philip > > > ----------------------------------------- 우지숙 (Woo, Jisuk) 서울대학교 행정대학원 Assistant Professor Graduate School of Public Administration Seoul National University tel: 82-2-880-5633 (tel) fax: 82-2-6248-0951(fax) email: jisuk(a)snu.ac.kr ------------------------------------------

1 0

[NCUC-DISCUSS] NCUC statement on Approval Process for Registry Services
by Marc Schneiders Jan. 14, 2004

Jan. 14, 2004

NCUC statement on "Procedure for use by ICANN in considering requests for consent and related contractual amendments to allow changes in the architecture or operation of a gTLD registry." NCUC observes that by initiating this procedure, ICANN is assuming that its contracts alone are not sufficient to provide a predictable and stable basis for the industry. It is assuming that it needs an ongoing form of oversight to supplement its contracts and contractual modifications, because the contracts cannot deal with all possible developments in the future. Thus, ICANN is expanding into additional areas of industry regulation, although no one wants to admit that. In formulating its response, NCUC begins by asking: How are noncommercial domain name users specifically affected by this change? The answer, NCUC believes, is that there is no commercial/noncommercial angle to this issue. It is more a question of: a) consumer protection; i.e., how users/consumers relate to suppliers and what kind of regulatory procedures are needed to protect consumers given the high switching costs associated with changing registry suppliers after a domain name is well-established. b) technical coordination; i.e., what kind of technical regulation or specifications are needed to protect third parties using domain names on the Internet from harmful changes made in registry operation, while preserving as much as possible the freedom of suppliers to respond to the market and innovate. NCUC notes that whether consumers or users are commercial or noncommercial has little bearing on these issues. We also note that a) and b) are distinct policy issues. a) Involves protection of the parties buying service from a gTLD registry, who may have options, while b) involves protection of third party users of a domain name, who probably do not have any options if they want to connect to the party using the affected registry. We also note that a) involves economic forms of regulation which also involves competition policy concerns, while b) is more a matter of technical coordination. NCUC strongly recommends that the PDP distinguish clearly between a) and b) in its consideration of the new process. Is the object of the process economic regulation or technical coordination? The document we are asked to comment on proposes no policies, so our comments can only suggest questions or problems for the PDP process to consider. 1. One question the PDP should consider is whether all issues related to a) above should be handled by national regulatory authorities instead of ICANN. We support ICANN's need for technical coordination related to matters under b). We are less confident of ICANN's ability and right to engage in a). We are also not convinced of ICANN's ability to engage in competition policy-related forms of regulation. We recognize, however, that it may be difficult for consumers to obtain adequate protection in a transnational business context. Additionally, registries and registrars can and do hide behind their contracts with ICANN. The structure of ICANN's contracts allows a willful registry or registrar to "hide the ball" by pointing to a different contracting party as responsible for the conduct the registrant complains of. Thus, registries maintain that contracts imposed by ICANN bar them from certain courses of action, registrars likewise claim that contract provisions imposed by ICANN prevent them from acting, and ICANN says it is not a regulator and that any remedy lies in the contracts which it claims are negotiated freely. At this moment, when we discuss the introduction of new regulatory procedures, ICANN has to make clear what its position precisely is vis-a-vis consumer protection. The new procedures developed in this PDP should certainly not worsen the situation described in this paragraph. While there is a case for a global governance regime, we note that ICANN invested most of its effort in protecting trademarks and domain name supplier interests, and has shown very little interest in protecting consumers and users. For ICANN to become an effective consumer protection agency significant changes would have to be made in its representational structure and decision making processes. 2. The PDP document refers to a "quick look" process followed by a more involved process if a change fails the "quick look." A question the PDP needs to face squarely is: What is a subject to a "quick look" and what is not? What is a "new registry service"? How is that defined? Who will make that determination initially? What happens when the registry and ICANN disagree on that issue? If a process is created, there should be guidelines as to when an issue is important enough to put it before ICANN bodies, invite public comment etc. Some issues will be too important to leave to ICANN staff. 3. The NCUC recognizes the danger that a registry can make damaging changes, such as in the Sitefinder case. We support clear, well-defined specifications for registry operation that make DNS a neutral platform for Internet functions. We also recognize a threat that innovative changes will be stifled by a central organization such as ICANN which may have incentives to prevent useful changes in order to maintain its control over the industry. 4. The PDP should consider whether there should be a distinction between policies applied to sponsored and unsponsored TLDs. NCUC believes the answer will be usually no. There have to be good reasons to make a distinction. If the justification for regulation is economic; i.e, that users are locked in to a supplier and cannot switch service providers without incurring damaging costs, then the same fundamental economic problem applies regardless of whether the registry is sponsored or not. In some respects, switching costs are more serious with sponsored TLDs, since they are supposed to represent a community identity and not just an individual company/organization's identity. If the justification for the review process is technical, the answer is the same: there is no relevant technical distinction between sponsored and un-sponsored registries. We do, however, believe that sponsored TLDs could be and should be required to consult their "community" before making changes in operation of the sort contemplated by the PDP. 5. The PDP should consider whether there should be a distinction between the treatment of dominant and non-dominant TLDs? In this case NCUC believes there is a stronger case for a distinction. A major dominant registry may have the power to move the entire industry and technology, whereas smaller ones would not. However, the lock-in problem of consumers applies regardless of whether the registry is dominant or not. As the Internet and DNS grow, larger numbers of users will be affected by TLD registries regardless of their overall share of the market. Thus, the policy must identify carefully what problem it is trying to solve. 6. We wish to emphasize that public consultation, and consultation of constituencies, must be a regular part of dealing with the most important issues. We do not want ICANN staff to handle substantive policy issues on their own.

2 4

BC Comments on Registry Services
by Grant Forsyth Jan. 12, 2004

Jan. 12, 2004

Dear Bruce and fellow councillors Please find attached a draft position from the Commercial and Business Users Constituency (BC) as a contribution to the GNSO Task Force on: Procedure for use by ICANN in considering requests for consent and related contractual amendments to allow changes in the architecture or operation of a gTLD registry. The BC has not completed its internal consultation on this matter and hence our contribution is only draft at this time. Additionally, while we have drafted specific responses to the four main tasks identified in the Staff Report and TOR, these are not included at this time and will be forthcoming when we are able to confirm the final status of our contribution to date. Business users and BC members rely upon a reliable, stable and secure Internet as the providers of critical connectivity and transport infrastructure of the Internet, developers of the applications and innovative use of the internet, and, of course, as day-to-day users of the Internet. For these reasons, changes to a core element of the Internet, ie. registry services of the gTLDs, are of critical importance. We look forward to contributing to the Task Force's work. Sincerely Elected Representatives of the BC Grant Forsyth Marilyn Cade Philip Sheppard

1 0

Private initiative and regulatory bodies and the feeling of being scr*
by Marc Schneiders Jan. 9, 2004

Jan. 9, 2004

I just read a message to some other list (tucows registrar resellers) that says that NetSol (the registrar) will also delete IDN names as of February 28, 2004. (I guess they missed out on the extra day February has this year.) It seems this is about .com and .net names. One has to transfer them to another registrar, they say, or they die. Welcome to Oklahoma. I am now very mad. It is time ICANN acts up or it will lose goodwill altogether. Can individual registrars do this? ICANN accredited? Does that mean anything? You can read the message I refer to below. I am not sure it is proper to attach it, but I see no other way to give you the information. The archives require a password, I think. Marc Schneiders --- NCUC council member --- Another one concerning Multilingual Domains. "On February 28, 2004, Network Solutions, LLC will no longer offer or support Multilingual Domain Name registrations (MDNs). A list of your domain name registration(s) affected by this change is provided below. In order to keep your .COM and .NET MDNs registered to you, you must transfer them to another provider before February 28, 2004. If these MDNs are not transferred, they will be deleted from our database which will make them available for registration by anyone. Your MDNs will continue to be listed in your Network Solutions(R) account until you complete the transfer process or until we delete them on February 28, 2004. You do not need to renew your MDNs in order to process your transfer. Please be assured that these changes only apply to Multilingual Domain Names. Network Solutions will continue to support your other domain name registrations and services. If you have any questions, please contact Customer Support at mailto:customerservice@networksolutions.com. Thank you for your prompt attention to this matter. Sincerely, Network Solutions(R) Customer Support Multilingual Domain Names with Network Solutions as of December 30, 2003: BQ--....COM ___________________________________________________________________ Please do not respond to this message. For inquiries, contact Customer Service at mailto:customerservice@networksolutions.com. (C) Copyright 2004 Network Solutions, LLC. All rights reserved." The Domain is still listed in race code in the nestol control panel but does not appear anymore in whois in race code. The whois output directly from netsol for the domain name in puny code looks like that (no owner info): Domain Name: XN--....COM Registrar: NETWORK SOLUTIONS, INC. Whois Server: whois.networksolutions.com Referral URL: http://www.networksolutions.com Name Server: NS1.TOTALCHOICEHOSTING.COM Name Server: NS2.TOTALCHOICEHOSTING.COM Status: REGISTRAR-LOCK Updated Date: 14-dec-2003 Creation Date: ..-aug-2003 Expiration Date: ..-aug-2005

2 2

Call for TOR change
by Grant Forsyth Jan. 9, 2004

Jan. 9, 2004

Dear Bruce , fellow Councillors and Barbara RE: Terms of Reference for Task Force on: Procedure for use by ICANN in considering requests for consent and related contractual amendments to allow changes in the architecture or operation of a gTLD registry. While we, the elected representatives of the Commercial and Business Users Constituency (BC), recognise that the Draft TOR were agreed by Council on 2 December 2003 and have been put out for public consideration and that submissions closed on 28 December 2003, due to the holiday period the job of developing the BC initial position on the matter has only now brought to light an undesirable "narrowness" of the TOR. Specifically we consider that two of of the three aspects recommended to be considered "Out of Scope" should be included in the PDP consideration, namely: A) Changes to the nature of the agreements between ICANN and the registry operators B) Additional obligations on registry operators or gTLD sponsors beyond what is already specified in their existing agreements We would note that the PDP under consideration is not focused on any particular registry service, action, change in architecture or operation, but rather on developing a procedure for consideration of any such change. For such a procedure to have maximum usefulness it: - should not embody any issue specific constraint (such as potential changes that might also be considered in the future policy development associated with the review of new gTLDs (out of scope A); and - must be flexible and forward looking such that the procedure can deal with changes in circumstances, markets or technology innovation not previously foreseen and explicitly captured in wording of existing contracts (out of scope B) We do not envisage the removal of these current "Out-of-scope" constraints to have any great impact on the PDP process, the complexity of response to the identified four main tasks or the final overall policy recommendation. In fact, seeking to embody the current out-of-scope constraints is likely to lead to a more convoluted procedure. Hence, we seek an amendment to the current draft of the TOR by the removal of the first two "Out-of-scope" constraints. AND We erquest that this matter be included on the agenda of the next GNSO call, scheduled for 22 January. Sincerely Elected representatives of the BC Grant Forsyth Marilyn Cade Philip Sheppard

3 2

RE: Call for TOR change
by Bruce Tonkin Jan. 8, 2004

Jan. 8, 2004

Hello Grant, I will include discussion of this proposed change in the terms of reference at the beginning of item 4 on the agenda for the meeting on 22 Jan 2004. Regards, Bruce -----Original Message----- From: Grant Forsyth [mailto:Grant.Forsyth@team.telstraclear.co.nz] Sent: Friday, 9 January 2004 7:28 AM To: Bruce Tonkin; GNSO SECRETARIAT; council(a)gnso.icann.org; 'roseman(a)icann.org' Cc: 'Philip Sheppard'; 'Marilyn Cade AT&T' Subject: Call for TOR change Dear Bruce , fellow Councillors and Barbara RE: Terms of Reference for Task Force on: Procedure for use by ICANN in considering requests for consent and related contractual amendments to allow changes in the architecture or operation of a gTLD registry. While we, the elected representatives of the Commercial and Business Users Constituency (BC), recognise that the Draft TOR were agreed by Council on 2 December 2003 and have been put out for public consideration and that submissions closed on 28 December 2003, due to the holiday period the job of developing the BC initial position on the matter has only now brought to light an undesirable "narrowness" of the TOR. Specifically we consider that two of of the three aspects recommended to be considered "Out of Scope" should be included in the PDP consideration, namely: A) Changes to the nature of the agreements between ICANN and the registry operators B) Additional obligations on registry operators or gTLD sponsors beyond what is already specified in their existing agreements We would note that the PDP under consideration is not focused on any particular registry service, action, change in architecture or operation, but rather on developing a procedure for consideration of any such change. For such a procedure to have maximum usefulness it: - should not embody any issue specific constraint (such as potential changes that might also be considered in the future policy development associated with the review of new gTLDs (out of scope A); and - must be flexible and forward looking such that the procedure can deal with changes in circumstances, markets or technology innovation not previously foreseen and explicitly captured in wording of existing contracts (out of scope B) We do not envisage the removal of these current "Out-of-scope" constraints to have any great impact on the PDP process, the complexity of response to the identified four main tasks or the final overall policy recommendation. In fact, seeking to embody the current out-of-scope constraints is likely to lead to a more convoluted procedure. Hence, we seek an amendment to the current draft of the TOR by the removal of the first two "Out-of-scope" constraints. AND We erquest that this matter be included on the agenda of the next GNSO call, scheduled for 22 January. Sincerely Elected representatives of the BC Grant Forsyth Marilyn Cade Philip Sheppard

1 0

PIR and stability and consumer protection?
by Marc Schneiders Jan. 8, 2004

Jan. 8, 2004

Perhaps more than a footnote to the present discussion of "Approval process for gtld service changes": PIR is going to delete all multilingual domains (also called IDN) on February 2004. I learned about this through the newsletter of a German registrar (quote below). I have protested earlier about the silent end to resolution (working DNS) of these domains in March 2003. PIR was not very responsive, to put it mildly. Now again there will be a secret change to these domains. They will quietly disappear. I see no message about it on the PIR website. I am of the opinion that this is unacceptable in several respects: 1. Registrants are not notified. I have such a domain and I heard nothing. 2. It is done in a most intransparent, even secret manner. 3. It is related to the redelegation of a TLD. Will the same thing happen in 2005 with .NET? 4. Multilingual domains were a private initiative of Verisign, not approved by ICANN, but neither did ICANN tell Verisign not to do it. In this context it is most relevant for the "approval process" topic. 5. PIR kills .ORG multilinguals for technical reasons, it says (well the German text below does). At the same time Afilias (which runs .ORG technically) is introducing multilingual .INFO domains. Can anyone explain this to me, please? >From newsletter of dd24.net: ---------------------------------------------------------------------------- PIR wird multilinguale .ORG Domains nun doch löschen ---------------------------------------------------------------------------- Nach einer anders lautenden Meldung im November hat uns das kürzlich ernannte Zentralregister für .ORG Domains, Public Interest Registry (PIR), jetzt darüber informiert, dass die Registrierungen der nach dem ehemaligen "RACE-Verfahren" eingetragenen multilingualen .ORG Domains (also Domains mit Umlauten bzw. Sonderzeichen) doch nicht länger kostenlos verlängert werden. Stattdessen hat sich PIR für eine Löschung aller multilingualen .ORG Domains zum 1. Februar 2004 entschieden. Gründe für diese Entscheidung sind insbesondere die technischen Schwierigkeiten und Unsicherheiten der zukünftigen Umwandlung der bereits registrierten Domains in das neue "Punycode-Verfahren". Nun muss zunächst einmal geklärt werden, auf welche Weise eine Neueinführung multilingualer .ORG Domains gemäß des allgemeinen Standarts zukünftig überhaupt durchgeführt werden soll. Wir sind gespannt... Quelle: PIR

1 0

REMINDER CONSTITUENCY STATEMENTS due on 12 JANUARY 2004
by GNSO SECRETARIAT Jan. 7, 2004

Jan. 7, 2004

[To: council[at]gnso.icann.org] REMINDER CONSTITUENCY STATEMENTS due on 12 JANUARY 2004 Procedure for use by ICANN in considering requests for consent and related contractual amendments to allow changes in the architecture or operation of a gTLD registry ("Approval process for gtld service changes") http://gnso.icann.org/issues/registry-services/tor-revised.shtml http://gnso.icann.org/meetings/minutes-gnso-02dec03.shtml The GNSO Council at the December 2 teleconference took the decision to undertake the policy development process as a committee as a whole and follow the policy development process with the requirements of public notice in compliance with the ICANN bylaws and procedure when no task force is formed. The Public Comment Period closed on December 28 2003. Comments received: http://gnso.icann.org/mailing-lists/archives/tor-reg/msg00002.html http://gnso.icann.org/mailing-lists/archives/tor-reg/msg00003.html Please submit your statements to the ICANN Staff Manager, Barbara Roseman: roseman(a)icann.org as soon as possible. Thank you very much. GNSO Secretariat

1 0

Draft agenda for Council meeting on 22 Jan 2004
by Bruce Tonkin Jan. 6, 2004

Jan. 6, 2004

Hello All, Below is a draft agenda for the teleconference scheduled for 22 Jan 2004. This call will be scheduled for UTC 1900. (11am Los Angeles, 2pm Washington DC, 7pm London, 6am (next day) Melbourne ) Item 1: Approval of minutes of last meeting - 18 Dec 2003 - Actions arising Item 2: Approve timelines for WHOIS task forces (30 mins) Receive an update from the WHOIS task force chairs: Brian Darville, Jeff Neuman, Jordyn Buchanan Approve timelines for: Submission of constituency statements Distribute Preliminary Task Force Report Publish Task Force Report (Initial Report) Publish Final Report Item 3: Discuss constituency statements on the Procedure for use by ICANN in considering requests for consent and related contractual amendments to allow changes in the architecture or operation of a gTLD registry [45 mins] - the intent of this discussion is to provide intput ot he Staff Manager to allow production of a Preliminary Report. Item 4: Planning for ICANN meeting in Rome [20 mins] - proposed four PDP workshops - Council breakfast and invitation to Board - Council meeting and invitation to Board Item 5: WSIS [15 mins] - Marilyn Cade to report on outcomes of WSIS and any recommendations for action by ICANN Item 6: Any other business Regards, Bruce Tonkin

2 1

GNSO Council draft minutes December 18, 2003
by GNSO SECRETARIAT Jan. 6, 2004

Jan. 6, 2004

[To: council[at]gnso.icann.org] Dear Council members, Please find attached and in text version the GNSO Council draft minutes of the teleconference held on December 18, 2003. If you would like any changes made please let me know. Thank you very much. Glen de Saint Géry GNSO Secretariat 18 December 2003. Proposed agenda and related documents List of attendees: Philip Sheppard - Commercial & Business users C. Marilyn Cade - Commercial & Business users C. Grant Forsyth - Commercial & Business users C. - absent, apologies, proxy to Marilyn Cade/Philip Sheppard Greg Ruth - ISCPC - absent, apologies, proxy Antonio Harris Antonio Harris - ISCPC Tony Holmes - ISCPC - absent, apologies, proxy Antonio Harris Thomas Keller- Registrars Ross Rader - Registrars Bruce Tonkin - Registrars Ken Stubbs - gTLD registries Jordyn Buchanan - gTLD registries Cary Karp - gTLD registries Lucy Nichols - Intellectual Property Interests C - absent, Niklas Lagergren - Intellectual Property Interests C.- absent, apologies, proxy to Philip Sheppard Kiyoshi Tsuru - Intellectual Property Interests C. - absent, apologies, proxy to Philip Sheppard Jisuk Woo - Non Commercial users C. Marc Schneiders - Non Commercial users C. Carlos Afonso - Non Commercial users C. - absent, apologies, proxy to Jisuk Woo Alick Wilson Demi Getschko - absent Amadeu Abril I Abril - absent 12 Council Members Kurt Pritz - ICANN Vice President of Business Operations Barbara Roseman - Staff Manager Christopher Wilkinson - GAC Liaison Thomas Roessler - ALAC Liaison Elisabeth Porteneuve - ccTLD Liaison The WHOIS Task Force Chairs were asked to join the call. Jeff Neuman - WHOIS Task Force 1 Chair Brian Darville - WHOIS Task Force 3 Chair Glen de Saint Géry - GNSO Secretariat MP3 recording Quorum present at 12:15 UTC, Bruce Tonkin chaired this teleconference. Item 1: Approval of the Agenda Item 2: Summary of last meetings: November 20, 2003 December 2, 2003 Ken Stubbs moved the adoption of the November 20, 2003 minutes. The motion was carried. Alick Wilson and Marilyn Cade abstained (absent at the meeting) Ken Stubbs moved the adoption of the December 2, 2003 minutes. The motion was carried. Tom Keller abstained. (absent at the meeting) Decision 1: Minutes of the November 20 and December 2 meetings adopted. Item 3: Update from WHOIS task forces - report on appointments of chairs and timelines for work program Task force 1: Restricting access to WHOIS data for marketing purposes - chair - Jeff Neuman Task force 2: Review of data collected and displayed - chair - Jordyn Buchanan Task Force 3: Improving Accuracy of collected data - chair - Brian Darville Jeff Neuman, WHOIS Task Force 1 chair, reported that the task was to collect information on the needs and justifications for non-marketing uses of WHOIS information and to look at the measures that are already in place or being developed to prevent data mining. In order to do this information, already available from the WHOIS workshops, surveys and former studies was being collected by the ICANN staff. A further task was the identification of "non-marketing groups" and soliciting their input on the needs and justification for the non-marketing uses of WHOIS data. Jeff Neuman requested that the GNSO Council accept the proposed time line stating that it was particularly aggressive to keep within the policy development process timelines and complete a Final Report. by March 1, 2004 for the ICANN Meeting in Rome.: 1) December 23, 2003: Dissemination by ICANN of all WHOIS workshop materials related to our specific issues and identification of non-marketing groups that use Whois Data. 2) January 5, 2004: First draft of Notice to non-marketing groups soliciting input on Task Force issues due to the Task Force 3) January 6, 2004: First draft of "needs and justifications" chart due (compiled from pre-existing data) 4) January 12, 2004: Send out Notice to non-marketing groups on "needs and justifications" for Whois data and for soliciting comments on "technical measures adopted for preventing data mining" 5) January 26, 2004: Due date for comments from "non-marketing groups" and "technical measures adopted for preventing data mining" 6) February 1, 2004: Constituency Statements due 7) February 9, 2004: Preliminary data due from ICANN, Registries and Registrars on "changes to agreements" to implement technical measures 8) March 1, 2004: Completion of a Final Report. The ICANN Rome meeting being the deadline for the preliminary report. Bruce Tonkin asked for clarification on "preliminary report", defined in the policy development process as the collection of constituency statements, information and public comments which were then discussed and later formed the task force report that was put out for public comment for a period of 20 days. Bruce Tonkin proposed that the timeline for the WHOIS task force I, which was an extension from the policy development process timeline be presented to the ICANN Board for approval. Ken Stubbs commented that time lines were too aggressive with the holiday period. Brian Darville, WHOIS Task Force 3 chair, reported that task force 3 was looking at current techniques that registrars are using to verify their WHOIS data. Questions would be sent to the Registrars on January 5 and they would have till January 15 to respond as that information would be a driver for other information needed. A preliminary report was planned for March 16, just after the ICANN Rome meeting. Kurt Pritz commented that additional data gathering time would be required to receive all the registrar responses. Bruce Tonkin suggested a two pronged approach for gathering the registrar's data, sending question to individual registrars and to the registrar's constituency. Kurt Pritz asked whether a statistical sample of data gathering was possible, to which Bruce Tonkin, from a registrars point of view, responded that it would depend on the questions asked. Marilyn Cade commented that there would be multiple and overlapping requests for data to ccTLDs, and third parties and as far as possible these should be coordinated. Bruce Tonkin made the distinction between collecting opinions and data collection and commented that the policy development process did not make provision for data collection. Past practice proved that opinions were better informed if they were based on shared data. Bruce Tonkin proposed working with the GNSO Secretariat and ICANN staff to produce a spreadsheet of the policy development process based on the milestones in the ICANN bylaws and draw a comparison with the dates that were proposed by the 3 task forces. It would indicate where activities needed to be synchronized and would serve to make a joint statement to the ICANN Board where extra time was needed in the ICANN community. Bruce Tonkin explained that the GNSO Council would formally have to vote on the recommendation for an extension of time and the ICANN Board would have to approve it as is specified in the ICANN bylaws: Section 7, Task Forces (b) 2. the specific timeline that the task force must adhere to, as set forth below, unless the Board determines that there is a compelling reason to extend the timeline; Marilyn Cade commented on a resource issue that affected the timing and suggested that appointing an expert within the task force or retaining a neutral person to do data gathering could be very helpful to the task force process. Bottlenecks could be created in the timing as too much work would depend on one person. The task forces should come up with a relatively consistent timeframe, as the GNSO council would still have to unify policy changes after the task force work was completed. Kurt Pritz responded that the subject of hiring experts had been discussed and would be approached when statements of work were specifically set out. Tom Keller expressed concern that appointing such a person could lead to subjective data gathering. Jordyn Buchanan remarked that given the alignment in dates for task force 2 and 3 there could be an increased burden on ICANN staff and constituencies towards the phase of the final report. Bruce Tonkin commented that a preliminary or draft report, should be completed by the ICANN Rome meeting. He suggested deferring the signing off date on a set of time lines for the 3 task forces until the GNSO Council meeting in January when the Council decision could be forwarded to the Board for approval In the mean time, in consultation with the task forces, the GNSO Secretariat and the ICANN staff he suggested doing a reiteration of timeframes that looked at sufficient time for data collection, ensuring input at the Rome meeting, and coordinating the questionnaire distribution. Bruce Tonkin stated that clarification had been sought on the role of alternates in participation on task force calls. At its meeting on 20 November, the GNSO Council decided: "That for the purpose of the WHOIS task forces, constituencies be allowed to appoint more than one person to listen in on teleconferences and to participate in the mailing list, but in any single teleconference or physical meeting, there is only one person from the constituency to represent the constituency's views." Brian Darville, chair of WHOIS task force 3, offered the following approach: "We do allow alternates to speak on issues of general informational interest. The scope of the Task Force's work encompasses gathering and analyzing information. Many of the alternates, some of whom have significant ICANN experience and historical knowledge, can contribute significantly in furthering the Task Force's work by simply providing historical information or indicating the availability of other information germane to the issues the Task Force is addressing. Of course, under no circumstances will any alternate be allowed to represent the views of the constituency or provide the vote of any constituency (unless the designated representative is absent on the call)." Philip Sheppard suggested that any constituency with more than one representative could decide for a particular call to designate the alternative as spokesman if that person had particular expertise to offer. It could be left to the discretion of the task force chair to decide which information should be accepted and to stop abuse of multiple interventions. Marilyn Cade added that in previous task forces, the Transfers and WHOIS, where there had been several representatives from one constituency, different people could contribute to the work of the task force but only one person was allowed to speak on a constituency view point and only one person was allowed to vote. Jeff Neuman suggested that a directive from the GNSO Council would be useful for the future. Bruce Tonkin proposed posting a directive to Council and the task forces making the distinction between an opinion, where there should be only one per constituency and factual information where the task force chair exercises discretion. . There was general agreement to this approach. Marc Schneiders commented that fact and opinion were not always clearly defined. Bruce Tonkin responded that if a constituency had an issue with participation by another constituency they could raise it with the chair of the task force, and if the issue could not be resolved, the constituency could raise the issue with the Council. Elisabeth Porteneuve, as a liaison from the ccTLD group, announced that WHOIS and WHOIS-related services would be dealt with at the next CENTR General Assembly, in mid-February 2004 in Salzbourg. The CENTR Secretariat was about to start the research and a survey would take place. If the GNSO Council or Whois TF 3 had specific questions on Whois data accuracy, they should be sent to the secretariat who would be happy to include them in CENTR survey. The CENTR plans to start the survey probably by 16 January, and close it two weeks later. An additional two weeks are necessary to write the report. The collected information/results will be available for the Salzburg meeting. Item 4: Preliminary views from constituencies on the Procedure for use by ICANN in considering requests for consent and related contractual amendments to allow changes in the architecture or operation of a gTLD registry - the intent of this discussion is to share any preliminary views from constituencies as they develop their constituency statements Item The GNSO secretariat gave an update on the person for each constituency coordinating the constituency statements: Grant Forsyth - for the Commercial & Business users constituency. Antonio Harris for the Internet Service and Connectivity Providers constituency Jordyn Buchanan for the gTLD registries constituency J. Scott Evans for Intellectual Property Interests constituency Marc Schneiders for the Non Commercial users constituency Registrars constituency - not certain All constituencies reported that it was probable the deadline of 12 January would be met for constituency statements. The constituency statements would then be collated into a single document. Bruce Tonkin proposed calling a GNSO Council meeting toward the end of January to conclude an initial report. Barbara Roseman commented that information should be solicited from other supporting organizations or advisory committees, to which Marilyn Cade added the ccNSO. Bruce Tonkin, as the GNSO Council chair, proposed formally requesting input from the Security Advisory Committee, the Address Supporting Organization, and the At Large Advisory Committee and the ccNSO. Item 5 Any Other Business Philip Sheppard raised the need, especially for communication purposes, to have a short title for: The Procedure for use by ICANN in considering requests for consent and related contractual amendments to allow changes in the architecture or operation of a gTLD registry. Barbara Roseman proposed working on a short title for communications. Philip Sheppard, who had been involved in preparing the original policy development process, proposed a guide for future Issues Reports in the light of experience that had been gained along the process. Proposed guidelines for the ICANN staff manager's issue report -version 1 Background The staff manager's issue report is the precursor to the GNSO policy development process (PDP). The PDP is relatively new and there has been a high degree of variation in the quality, length and usefulness of the issues reports so far. This is not surprising since Council and staff are still developing procedures. Therefore, Council proposes guidelines to provide structure for future staff manager issue reports. The goal is to ensure that the materials are directly useful to the work of the Council. Objective An issue report has three objectives: - Relevance: to confirm an issue is within ICANN's mission, - Description: to explain what the issue is, who it affects, what support there is to address the issue, - Recommendation: to recommend whether or not the GNSO should start a PDP. The by-laws lay down a structure as to how the above objectives may be met. http://www.icann.org/general/bylaws.htm#AnnexA What SHOULD NOT be in the issues report The report has a short time frame (15 calendar days). This tells us that it is NOT intended to contain: - options for solutions, - options for how the Council may proceed, - responses to a formal consultation of constituencies (this comes later if the PDP goes ahead), - nor should it be necessary to supplement it with documents such as FAQs. What SHOULD the issues report look like? It should be the primary document needed for the Council to make a decision whether to proceed or not with a PDP. It should include links to existing documents that provide directly relevant background. The report must be clear in its recommendation to Council. Past reports have not had this clarity and the GNSO chairman has been obliged to draft terms of reference for a Council WG in an attempt to provide such clarity. It would be more appropriate if the report itself proposed such terms of reference (recognising that Council may choose to modify them). Therefore all future issues reports should contain: - proposed terms of reference for a Council working group drafted in a practical and manageable way and reflecting a possible priority of sub-issues. The length of an issues report will be guided by the topic. Some issues reports may be very short; others may be lengthier but none need be long. Summary of guidelines The issue report should: 1. Describe an issue but NOT explore options. 2. Provide directly relevant background and links. 3. Recommend whether to proceed or not. 4. Propose terms of reference for a Council WG. 5. Be provided to Council within the 15 day time frame laid out in the by- Bruce Tonkin thanked Philip Sheppard for the contribution and suggested that Council members read the document which would be discussed at a later GNSO Council meeting. Marilyn Cade commented to Kurt Pritz on the change in the schedule for the Rome meeting which could present an imposition on the community that would like to be there during the whole process. Kurt Pritz responded that there had been much discussion on the issue and that community feedback was useful. Bruce Tonkin declared GNSO meeting closed, thanked everybody for attending and wished everyone a happy holiday season. The meeting ended: 13:23 UTC Next GNSO Council teleconference: TBD see: http://gnso.icann.org/calendar/

1 0

RE: [council] Rome meeting
by Bruce Tonkin Jan. 6, 2004

Jan. 6, 2004

Hello Marilyn, > > 1. As we are beginning to plan for the Rome ICANN meeting, > I'd like to suggest that Council consider the time frame for > our meeting and our working agenda and adjust, IF needed, to > ensure that we have time to address in detail the issues on > our agenda. At our last meeting in Carthage, we had a number > of issues to discuss and needed to extend our meeting > accordingly. Fortunately, we were able to do so. However, we > may not always be so fortunate with availability of rooms, > staff, bridge, remote participants availability. I see from the preliminary planning for the ICANN meeting that 2 March 2004 is for constituency meetings 3 March 2004 is for the GNSO Council 4 March 2004 is for the public forum I suggest we project manage the whole day on 3 March 2004 as follows: Morning - 4 parallel sessions on the 4 PDPs (main policy work) - these will be public workshops managed by each task force/council - the objective will be to gain public input as well as seek to reach consensus positions Afternoon - Council meeting (mostly administrative) I am tempted to devote the whole day of 3 March on the policy workshops, and delay the council meeting until the morning of 4 March 2004. I can't think of too many issues before the Board at present that would justify a day long public forum, and I think the Council could benefit from having more time prior to the actual meeting workshopping some of the policy issues. Regards, Bruce

1 0

GNSO Council meeting dates
by Bruce Tonkin Jan. 6, 2004

Jan. 6, 2004

Hello Glen, Lets set up some basic dates for GNSO teleconferences for 2004 as follows: 22 Jan 2004 5 Feb 2004 19 Feb 2004 3 March 2004 (Rome) Regards, Bruce

1 0

Policy development timelines for task forces
by Bruce Tonkin Jan. 6, 2004

Jan. 6, 2004

Hello All, We are currently running 4 PDPs in parallel. Attached is a table in Microsoft Excel format that sets out: (1) The PDP milestones obtained from the bylaws (2) The dates required in the bylaws referenced to the date when the council requested an issues report for each PDP (3) Revised dates (either relative to when various reports have actually been complete, or as approved by Council) (4) Actual dates The table will be useful in assessing how realistic the timelines in the bylaws actually are based on experience, and also in scheduling the activities of the Council. I would like each task force chair to update the "revised" dates for the major PDP milestones, and fill in their own milestones to assist cooperation between the task forces. I have attempted to fill out the table for task force 1 based on their list of milestones. This will then allow the council to reach agreement on the timelines for the task forces at the next Council meeting and then subsequently present this to the ICANN Board for their endorsement. The key dates that need to be approved by Council and if necessary by the Board are: Submission of constituency statements Distribute Preliminary Task Force Report Publish Task Force Report (Initial Report) Publish Final Report My recommendation for each PDP is to attempt to create at least a "Preliminary Task Force Report" containing the constituency statements, initial public comments, and other information that has been collected at least 7 days prior to the Rome meeting (2 March 2004). This report need not contain the actual policy recommendations, but will form a useful basis to run focussed workshops during the Rome meeting to attempt to reach a consensus to create a task force report. This also means that all constituency statements and data collection should be complete by mid February 04. We should cordinate with ICANN staff to ensure that we can schedule open workshops with meeting rooms for each of the PDPs during the Rome meeting. I expect that a significant amount of time will be needed between the publication of the preliminary task force report documenting the postiions, and the actual policy recommendations. Overall for each of the PDP activities we should aim for the Council to approval new policies by the end of May, well in advance of the ICANN meeting in early July 2004. This will allow the Board sufficient time to review and approve the policy recommendations. Regards, Bruce Tonkin

1 0

RE: [council] Rome meeting, and WSIS
by Cade,Marilyn S - LGCRP Jan. 4, 2004

Jan. 4, 2004

Thanks, Mike. I am aware that the Board monitors the Council remotely. :-) But, you know that old saying, "Nothing like being there" ... especially when one is "there"... already. As to changing schedules, I know we all appreciated that. Thanks for the reminder about breakfast. I'm sure that Bruce already intends to invite the full board and all liaisons, but I'll suggest that we add that to Council's agenda to confirm as well. EARLY, so that time conflicts can be avoided. Best regards, mcade(a)att.com -----Original Message----- From: Michael D. Palage [mailto:michael@palage.com] Sent: Sunday, January 04, 2004 3:12 AM To: Cade,Marilyn S - LGCRP; GNSO Council (E-mail) Subject: RE: [council] Rome meeting, and WSIS Marilyn: Although I can only speak for myself, I believe all Board members appreciate the importance of the Names Council. What you may not realize is that although many Board members (including myself) were not in physical attendance during the Tunisia meeting, we were monitoring the Names Council meeting via web cast from the Board meeting room. I believe the Board's appreciation of the Names Council's role was evident by the fact that many of us rearranged our schedules to attend the Names Council breakfast in Tunisia, as well as the fact that certain key issues were changed based upon the Names Council's feedback. I hope this helps. Best regards, Michael D. Palage -----Original Message----- From: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org]On Behalf Of Cade,Marilyn S - LGCRP Sent: Saturday, January 03, 2004 9:33 PM To: GNSO Council (E-mail) Subject: [council] Rome meeting, and WSIS I know that our exact date for Council isn't set yet, but I assume it is to be announced for the next two weeks, therefore, I'd like to introduce three items for discussion on our upcoming agenda. : 1, Ensuring appropriate time available for dealing with Council's agenda at Rome 2. Attendance/invitation to the Board to attend Council's meeting 3. WSIS follow up 1. As we are beginning to plan for the Rome ICANN meeting, I'd like to suggest that Council consider the time frame for our meeting and our working agenda and adjust, IF needed, to ensure that we have time to address in detail the issues on our agenda. At our last meeting in Carthage, we had a number of issues to discuss and needed to extend our meeting accordingly. Fortunately, we were able to do so. However, we may not always be so fortunate with availability of rooms, staff, bridge, remote participants availability. I ask that Glen and Bruce look at our planned agenda and determine whether we may need a longer meeting than the two hours that are usually provided. After all, Council only meets in person approximately 3 times a year. We should plan ahead, if needed, for a longer meeting, so that we can fully address the issues on our agenda. 2. As I've participated in Council at ICANN's meetings, I've noticed a lack of attendance by the full Board. Since Council is one of the two important policy making bodies of ICANN, attendance at the Council meetings should be of interest and importance for all Board members. Bruce, perhaps we could discuss, briefly, at our next call, sending an invitation to both the Board and the GAC to attend the Council's meeting. 3. Finally, I'd like to add the topic of follow up to the WSIS to our Council agenda. ICANN is a sub-theme to the WSIS activities, but of course, we are all concerned that the larger set of activities of the private sector in addressing the WSIS, take into account and fully represent the views of ICANN's supporters. I'd like to report on the outcome of the WSIS, and suggest that Council continue to monitor the work underway by the private sector related to the WSIS, including, as appropriate, providing advice to the Board on the WSIS activities, and how ICANN might participate in the larger WSIS activities. Marilyn mcade(a)att.com

1 0

Rome meeting, and WSIS
by Cade,Marilyn S - LGCRP Jan. 4, 2004

Jan. 4, 2004

I know that our exact date for Council isn't set yet, but I assume it is to be announced for the next two weeks, therefore, I'd like to introduce three items for discussion on our upcoming agenda. : 1, Ensuring appropriate time available for dealing with Council's agenda at Rome 2. Attendance/invitation to the Board to attend Council's meeting 3. WSIS follow up 1. As we are beginning to plan for the Rome ICANN meeting, I'd like to suggest that Council consider the time frame for our meeting and our working agenda and adjust, IF needed, to ensure that we have time to address in detail the issues on our agenda. At our last meeting in Carthage, we had a number of issues to discuss and needed to extend our meeting accordingly. Fortunately, we were able to do so. However, we may not always be so fortunate with availability of rooms, staff, bridge, remote participants availability. I ask that Glen and Bruce look at our planned agenda and determine whether we may need a longer meeting than the two hours that are usually provided. After all, Council only meets in person approximately 3 times a year. We should plan ahead, if needed, for a longer meeting, so that we can fully address the issues on our agenda. 2. As I've participated in Council at ICANN's meetings, I've noticed a lack of attendance by the full Board. Since Council is one of the two important policy making bodies of ICANN, attendance at the Council meetings should be of interest and importance for all Board members. Bruce, perhaps we could discuss, briefly, at our next call, sending an invitation to both the Board and the GAC to attend the Council's meeting. 3. Finally, I'd like to add the topic of follow up to the WSIS to our Council agenda. ICANN is a sub-theme to the WSIS activities, but of course, we are all concerned that the larger set of activities of the private sector in addressing the WSIS, take into account and fully represent the views of ICANN's supporters. I'd like to report on the outcome of the WSIS, and suggest that Council continue to monitor the work underway by the private sector related to the WSIS, including, as appropriate, providing advice to the Board on the WSIS activities, and how ICANN might participate in the larger WSIS activities. Marilyn mcade(a)att.com

2 1