Intent and Authority : Based on ICANN Bylaw section 2.3 [AG2] , which states: ”To the extent feasible and appropriate, delegating coordination functions to or recognizing the policy role of other responsible entities that reflect the interests of affected parties” [AG3] we the At-Large community propose the following agenda to enhance consumer protections and end user accountability within the Domain Name System in order to hold ICANN to mission statement: ”(3) This Corporation is a nonprofit public benefit corporation and is not organized for the private gain of any person...The Corporation is organized, and will be operated, exclusively for charitable, educational, and scientific purposes ... pursue the charitable and public purposes of lessening the burdens of government and promoting the global public interest... AND (4) The Corporation shall operate for the benefit of the Internet community as a whole"
1. Standard for ICANN work (the "Preamble Principle”)
Our proposal is to attach a mandatory document and test to all ICANN policy changes, expenditures, and DNS expansion [AG5] projects. This required preamble to all ICANN work will be an explanation of the expected impact and/or benefit of the particular work to the consumer and end-user. The intent of this preamble will be to help guide ICANN’s work to focus on the user in the way it conducts all business. In most cases, this would be a brief paragraph describing how a particular policy change or project would affect the Internet user. In issues of expenditure over a to-be-determined amount, a cost-benefit analysis. The concept is ultimately simple, no work should begin and money should be spent until the possible impact on the Internet user or the intended benefit is stated. This is not a prediction of outcome, but an alignment of goals.
Example: Improving DNS Security
Q: ”How will this impact/benefit Internet users?"
A: "Improving DNS Security will improve overall security for the Internet user”
Example: Document Disclosure
A: "Increasing access to ICANN documents will improve transparency to the Internet user"
2. Restructuring of ICANN Compliance
Actions and decisions of ICANN Compliance impact consumers on many levels world-wide. However, ICANN Compliance is imbedded in within the Business division of ICANN. As a
simple structure this would appear to be a conflict of interest for an organization that exists as a public benefit corporation. Clearly, specific contractual compliance is a
concern and the execution of compliance actions should be a legal function. However, the community has minimal insight into practices and work of ICANN compliance. ICANN Staff often views the relationship between ICANN and contracted parties as a private relationship. However, the structure of ICANN makes this much more complex. A separation of compliance functions with more community oversight is called for. Some of the
options to consider are A) Making compliance report directly to the
Board, B) Separating legal contract
from technical compliance investigation, C) Creating a cross-constituency review committee for
compliance decisions, D)
Completely outsourcing compliance, or some
combination of changes.
3. Direct Messaging to the Consumer
ICANN has developed guides for attorneys, journalists, and law enforcements but not for consumers. Existing “beginners guides” deal specifically with At-Large and not end users. Our proposal is the development of a Consumer Guide to ICANN as a collaboration between ICANN staff and At-Large [AG11] to ensure that the message ultimately reflects a mutual understanding between ICANN and the consumer.
4. Due Process for Domain Disputes
At the moment, there two methods for disputing a domain name: 1) through an inaccurate WHOIS record and 2) trademark infringements through UDRP/URS. These two situations do not represent the various issues consumers might have with domain names [AG12] . The total measure of consumer complaints (as they apply to domains) should be measured and it should be then determined if there is an ICANN process. if a process exists it needs to be promoted and analyzed, if it does not exist it should be created.
The community is regularly provided with statistics on domain registration but with little data on actual use of the DNS. It would be useful from a consumer perspective to understand how the DNS is being used, for example: how many existing domain names are actually in the zone files or linked to an IP address? How many domain names are in active use as websites or name servers as opposed to simply being warehoused? How many domains were used in abusive attacks or compromised by malware in a given year? How many domains were used in spam this year? How many domains had intrusions at the registrar, registry or hosting levels? How many domains are owned by commercial entities as opposed to individuals? How many domains are engaged in commerce and how many are purely informational? [AG14]
These are the kinds of statistics that would tell us in fact how the Internet is being used and how consumers may be impacted.
[AG1] Overall a great initative!
[AG2] Article I, section 2.3
[AG3] I don’t see the connection between this Bylaw clause and what we are doing. As an Advisory Committee, it is within our rights to advise the Board and ICANN that we should take this action.
[AG4] This definition, in theory, allows us to use the word in this context, but it is a new construct for ICANN and many people have objected that it is an inappropriate use of the term, focussing on the implication that consumer implies a financial transaction (which it does not in my mind). Far better to use “user” and avoid the entire issue. In fact, later in the document, “user” is used in this context.
[AG5] This is not a term that is used or perhaps even makes sense. I think you mean expansion of the name space.
[AG6] I think that this is a poor example. Transparency does not generally impact users directly. It impacts them because good transparency ensures proper oversight and increases ICANN’s credibility.
[AG7] Does not belong here. This is an internal At-Large/ALAC matter, not one for wider ICANN consideration.
[AG8] Agree with Sebastien. Phrasing it like this makes it sound like compliance should report to ICANN Legal.
[AG9] Execution of contract can mean the carrying out of all provisions, but often refers to just the signing of a contract. Perhaps “enforcement” here.
[AG10] Some combination is good. Complete outsourcing is probably not viable, as it implies outsourcing of the enforcement of the contracts signed by ICANN and I don’t think that is possible.
[AG11] Often when we propose such an initiative (and we have multiple times), no one steps up to actually do the work.
[AG12] I agree that it is currently an easy answer to say “not our job” and reject or redirect a complaint. But some of them are indeed not our job or not valid, so this statement has to have some conditions applied. Otherwise the edge cases will be used to reject the entire concept.
[AG13] I agree that these are all good things, but I would have thought that at least some of them are already being done. I suspect you are saying that ICANN should take ownership of the task.
[AG14] I’ve highlighted this one sentence but my comment applies to others as well. How much of this is really information that can be obtained, and how does one make the judgement calls required?