Comments on Draft auDA Registrar’s Code of Practice David Lindsay Research Fellow, Melbourne Law School 1. Purpose of these comments The purpose of these comments is to assist in refining the draft auDA Registrar’s Code of Practice (the ‘draft Code’). The Code is an important component of the self-regulatory regime for the .au namespace. The comments reflect my views alone. 2. General comments 2.1 The draft Code is well-intentioned. Most of the detailed rules are useful and have obviously been the subject of careful thought and debate. Nevertheless, in my view, considerable work is required before the draft Code is ready to be published in final form. 2.2 There are weaknesses in the drafting adopted by the draft Code. The wording of many provisions manages to be unnecessarily complex and imprecise. There is an over-reliance on vague terms that, in practice, may mean little. In short, the Code needs a thorough re-drafting. I would suggest that this task be given to a sub-group of the Code of Practice Committee, or to someone with experience in drafting codes such as this. 2.3 As members of the Code of Practice Committee will be aware, considerable work has been undertaken in relation to the development of codes of practice in the telecommunications industry. In this respect, the Australian Communications Industry Forum (ACIF) document, Guideline – Development of Telecommunications Industry Codes (January 1998), is especially useful. This document includes a ‘template’ for codes of practice that is based on a structure recommended by the Ministerial Council on Consumer Affairs (MCCA) guideline, Fair Trading Codes of Conduct – Why have them, how to prepare them? (latest version, June 1998). It is unclear to me why the draft Code deviates from the structure suggested by the MCCA and ACIF to the extent that it does. In particular, I would suggest that the draft code could be improved by adopting a structure that systematically deals with the following matters: * Scope * Objectives * Core rules * Complaints, dispute procedures and sanctions * Administration of the code * Publicity and reporting * Monitoring, review and amendments 2.4 The draft code could make much greater use of sub-headings. It needs a Table of Contents. The sections of the draft code dealing with enforcement could be improved by the use of flow charts. Relevant material referred to by the draft code (such as the National Privacy Principles) should be added as appendices, so that the document can be read without extraneous aids. 2.5 I would suggest renaming the code to something like ‘Registrars’ (and Domain Suppliers’) Code of Practice’. This may assist in making it clear that the code is intended to apply to resellers as well as registrars. 2.6 The draft Code includes a Glossary of Terms. Usual practice in drafting a document such as this is to have a separate section for definitions, rather than a glossary. More importantly, terms defined in the glossary should be used consistently throughout the document. For example, the glossary defines the term ‘Domain Name Supplier’, but the operative provisions of the draft code often use the term ‘domain name provider’. Is a supplier different from a provider? The draft code also uses some terms that need to be defined. I would suggest adding definitions of terms such as ‘registrar-of-record’, ‘registry database, ‘WHOIS data’, ‘domain name licence’, ‘advertising material’ and ‘TTY access’. The definition of ‘bad faith’ is effectively meaningless (I thought the UDRP was imprecise!). I would be interested in knowing what the Code Committee believes can be achieved by including such a broad subjective definition as this. The definition of a ‘customer’ needs more work (especially para (b) of the definition). If there is an official definition of a term, such as in a RFC, this should be referenced if appropriate. 2.7 In drafting a document such as this, it is best to liberally apply ‘Occam’s razor’. Most provisions can be written in a simple, straightforward manner. Unnecessary duplication should be avoided; unnecessarily elaborating on a straightforward general rule often results in confusing signals being sent. 2.8 The following comments on the drafting of the code deal with issues under the headings set out in the code. 3. Preamble 3.1 Much of the material in the preamble is unnecessary. I would suggest replacing the preamble with a statement headed ‘background’, which explains, in factual terms, the background to the code. 3.2 The following clauses seem to mean very little: cll 1.1, 1.2, 1.5. The first sentence of cl 1.2 is meaningless. Whether or not the code ‘clearly’ sets out anything is a matter of judgment. The phrase ‘newly competitive’ is unnecessary and will date the code. The code does not, and cannot, comprehensively deal with ‘the way in which registrars will operate’ (obviously, it deals with a sub-set of ‘the way in which registrars will operate’). The second sentence of cl 1.2 is significant. More explanation of the significance of the Registrar Agreement might help. 3.3 In relation to cl 1.4, it is preferable to set out what the code does, rather than what the code ‘seeks to’ do. Just say something like ‘the code ‘establishes a comprehensive process for dealing with consumer complaints in the domain name industry'. 3.4 Cl 1.6 is taken directly from the objectives of the ACIF Industry Code Complaint Handling (ACIF C547 October 2001). It is unclear to me why the objectives of another code should be incorporated wholesale into the preface of this code. I suggest that the committee think more carefully about what it is seeking to achieve with the preamble. 4 Purpose of Code 4.1 It is usual to refer to ‘objectives’ rather than ‘purpose’ (a less precise term). 4.2 Cl 2.1 does not set out the objectives or purpose of the code, but rather the intentions of the industry in developing a code. If the committee is somehow attached to this clause, I suggest that it be included in the background to the code, and not in an objects clause. 4.3 Cl 2.2 is imprecise and has nothing to do with the ‘purpose’ of the code. It seems to purport to impose some ill-defined obligation on registrars and resellers to ‘behave ethically and honestly’. What does this mean? The committee seems to be under the impression that a code of practice is mainly about industry ethics (something like the Hippocratic oath in the medical profession). There may well be an ethical component to a code of practice. But I would suggest that it is more important to communicate that providing accurate information to consumers, and preventing practices that undermine the reputation of the industry, is in the interests of the industry as a whole. 4.4 The objectives of the code need to be spelt out with considerably more precision. If the objectives are vague and nebulous, how can we be sure that the code is achieving the objectives? I would suggest something like the following: The Code is intended to promote the interests of the domain name industry and customers by: (a) establishing minimum standards for dealing with customers; (b) ensuring that customers receive accurate and complete information concerning domain name registrations, renewals and solicitations; (c) ensuring the accuracy of domain name advertising and promotional material; (d) establishing minimum standards in relation to complaint handling by domain name suppliers; and (e) establishing procedures for dealing with breaches of the Code. 5. Implementation and Compliance 5.1 It is conventional to deal with this under the heading ‘scope’. Clause 3.1 is imprecise and open-ended (is that the intention?) It could be re-worded as follows: This Code applies to: (a) auDA Accredited Registrars; and (b) all other domain name suppliers that subscribe to the Code. 6. Domain name registrations 6.1 Clause 4.1 seems straightforward to me. The one issue of construction raised by the clause is what amounts to a ‘legitimate’ registration. The Committee may wish to consider the implications of deleting the word ‘legitimate’ in order to promote greater clarity, and avoid the possibility of a loophole. It is conceivable that some domain name suppliers may develop their own ideas about registering domain names to prevent ‘illegitimate’ registrations. if the term ‘legitimate’ were to be retained, I would suggest supplying some examples. The use of examples in italics is good practice. 6.2 Clause 4.2 seems to me to be quite clear. I am not sure that cll 4.3 and 4.5 add much to this at all. The only matter for interpretation in cl 4.2 is what amounts to a ‘request’. This could probably be dealt with by providing a gloss on the clause. I would suggest deleting cll 4.3 and 4.5 and dealing with these matters as examples of where there will be a breach of cl 4.2. Ideally, cl 4.2 should be expressed as being subject to cl 4.4. 6.3 The second sentence of cl 4.5 has no operative effect, as registries are not bound by the Code. It should be included as an explanatory note, not as an operative provision. 6.4 Clause 4.6 would be better expressed as ‘must’ rather than ‘can’. The second sentence is a little awkward. It could be re-worded to something like: ‘Where domain name services are provided for periods longer than 2 years, the domain name supplier must clearly inform customers that the domain name licence must be renewed every 2 years’. 7. Customer Contact 7.1 This is obviously a vitally important component of the code. I am not sure customer contact is the correct heading for the section. The Committee may wish to consider using headings such as ‘renewals’ and ‘other dealings with customers’. 7.2 A potential loophole with cll 5.2 and 5.3 is use of the phrase ‘a specific domain name licence’. Does this mean that general notices of renewal are acceptable? This may depend upon how the communication might ‘reasonably be construed’. Perhaps reference to ‘specific’ domain name licence could be deleted. A suggested re-wording might be ‘for a domain name licence or licences’. It seems to me that the point is to distinguish between something that may be construed as a notice of renewal and genuine solicitations for business. Some examples might help. 7.3 Clause 5.6 should refer to cll 5.1 to 5.5 (not (1) to (5)). For added certainty, an additional cl 5.6 factor could be considered, such as: ‘it cannot reasonably be construed as a renewal notice’. 7.4 Cll 5.7 and 5.8 could be grouped under a separate heading, such as ‘correction of WHOIS data’. 8. Advertising Principles 8.1 On my copy of the draft code (downloaded from auDA web-site) the second sentence of cl 7.1 makes no sense. One difficulty with this clause is that it appears to impose quite an onerous burden on auDA enforcement activities. The Committee may like to consider whether it is reasonable to expect auDA to be aware of ‘all legislation and published standards applicable to advertising of any product or service’. For example, does this include self-regulatory advertising codes? The issue here, I guess, is whether auDA should refer potential breaches to the relevant authorities, such as the ACCC; or whether it should be enforcing laws and rules relating to advertising itself? I am not at all sure that auDA is equipped to make judgments in relation to all matters concerning advertising laws and codes. At the least, I would suggest that the clause be modified to expressly apply only to the advertising of domain names and domain name services. 8.2 In relation to cl 7.2, it is quite unclear to me what is meant by ‘the level of information must be maintained throughout the customer’s continued use of the product’. I would have thought that it might be more practical to impose an obligation to inform customers of any material changes in the information relating to the terms and conditions of domain name registration. It may be possible to combine cll 7.2 and 7.3, which deal with similar matters (the precise relationship between 7.2 and 7.3 is unclear). In fact, I would have thought that the matters dealt with in cll 7.2 to 7.4 could be dealt with better in one omnibus provision, dealing with the accuracy, currency and completeness of customer information. 8.3 Cll 7.2 to 7.4 are grouped under the heading ‘advertising principles’, but seem to apply more broadly to ‘customer information’. The headings for sections 7 and 8 of the code are confusing. 9. Advertising Guidelines 9.1 In relation to cl 8.2, the phrase ‘who see or hear the advertising materials’ is unnecessary. 10. Comparative Advertisements 10.1 In relation to cl 9.1, the phrase ‘for the purposes of encouraging the customer to select a particular domain name supplier’ appears unnecessary. I am not sure that cl 9.5 adds anything to the general rules relating to disclaimers. Moreover, it may be better to deal with the matter dealt with by cl 9.6 (currency of information’) as a general advertising principle, rather than as a rule relating to comparative advertising. 11. Consumer Information 11.1 The draft Code uses the term ‘customer’ rather than ‘consumer’ throughout, but uses ‘consumer’ in the heading for this section. The reasoning behind the adoption of these terms seems obscure. An alternative might be ‘registrants’ and ‘potential registrants’, although I am not sure that ‘consumer’ is entirely unsuitable. 11.2 Clause 10.2 should be paragraph (b) of clause 10.1, or else expressed in different terms. 12. Conduct of employees, etc 12.1 Clause 11.3 is vague on the consequences of a breach of the code by employees, etc. It seems to me that the position of resellers and agents (that are domain name suppliers) may well require separate treatment to the position of employees and contractors. I would suggest that the consequences for resellers and other domain name suppliers be spelt out in more detail (with cross-reference to enforcement provisions). I would be inclined to consider imposing an obligation on a registrar to inform auDA if it discovers that a reseller is breaching the code (especially for serious breaches). 13 Consumer protection 13.1 The NPPs should be set out in an appendix. auDA should consider developing procedures for referring complaints relating to breaches of the NPPs to the Office of the Federal Privacy Commissioner. 14 Code enforcement 14.1 Clause 14.1 does not belong in the section of the code headed ‘code enforcement’. If anywhere, it belongs in a preamble or background section of the code. 14.2 I recommend the addition of flow-charts to explain the procedures set out in cll 13.2 and 13.3. Each clause could be more precisely worded. For example, step 1 of clause 13.2 should impose an obligation on a registrar to refer an unresolved complaint to auDA. For example, it could be re-written as follows: If a complaint is not resolved in accordance with the registrar’s complaints handling process, the registrar must notify auDA of the complaint, and provide auDA with all relevant documents. 15 Complaints handling procedures 15.1 Clauses 14.1 and 14.2 really say very little. In drafting clauses such as these, there are always questions as to how such vague terms can be enforced. It might be better to refer to some of the terms used in current cl 1.6. For example, a possible provision could say something like: Domain name suppliers must provide an efficient, fair and accessible mechanism for handling customer complaints. Domain name suppliers must demonstrate a commitment to the right of customers to complain and regard complaints as an opportunity to improve products and services. 16 Powers of auDA 16.1 Clause 15.1 is not an operative provision of the code. It belongs in the preamble or background section of the code. The section of the code should be headed ‘Complaints to auDA under this Code’. 16.2 Clause 15.4 uses the term ‘code signatories’, but this term is undefined. Do code signatories include auDA accredited registrars (which presumable do not need to ‘sign on’ to the code, as they are already bound by the agreement with auDA. I suggest that an obligation be imposed on accredited registrars and resellers who agree to be bound by the code to provide information to auDA concerning their complaint handling procedures (in addition to the annual information). This should act as an incentive for the development of such procedures. The Committee could consider the possibility of developing guidelines for complaint handling procedures. 17 Complaints handling procedures 17.1 The major problem with the provisions relating to complaints handling procedures is that they appear to be silent on the matter of the information to be given to unsuccessful complainants (other than frivolous or vexatious complainants – cl 16.13(l)). I would suggest that an obligation be imposed on domain name suppliers to provide complainants with standard form information in relation to actions that are available if a complaint is unsuccessful on the merits. The options available to consumers include taking the complaint to the ACCC, the Privacy Commissioner or, in the event of a complaint relating to potential breaches of the code, making a complaint to auDA. Although it is proper that the burden of dealing with complaints should rest with domain name suppliers, there is a need for consumers to be informed of the recourse available in the event that a satisfactory response is not forthcoming from a domain name supplier.