January 2004 - council - lists.icann.org

"Approval Process for gTLD Service Changes": Constitiency statements
by GNSO SECRETARIAT 03 Feb '04

03 Feb '04

[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 22 Jan '04

22 Jan '04

[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 21 Jan '04

21 Jan '04

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 21 Jan '04

21 Jan '04

Test =) sxeaovyr -- Test, yep.

1 0

Preliminary ALAC remarks on new registry services.
by Thomas Roessler 17 Jan '04

17 Jan '04

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 16 Jan '04

16 Jan '04

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 14 Jan '04

14 Jan '04

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 14 Jan '04

14 Jan '04

> 받는사람 : 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 14 Jan '04

14 Jan '04

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 11 Jan '04

11 Jan '04

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