From: David Keegel Sent: Wednesday, 13 June 2001 3:10 PM To: jo.lim@auda.org.au Subject: Submission for Competition Panel 4.2 Policy Authority The panel recommends a change in the structure of policy authority in the .au space, but does not suggest how to implement this change. In the interests of clarity, policy authority in .au is currently de-centralised, with 2LD managers (and in .id.au, 3LD managers) having policy authority for the respective 2LDs/3LDs. A table of policy authorities would look something like this: Domain Manager com.au auDA net.au Chris Chaudy/connect.com.au edu.au auDA (temporarily?) gov.au OGO/NOIE asn.au Michael Malone info.au Robert Elz dropbear.id.au Stuart Bishop echidna.id.au ConnectWest emu.id.au Lawrie Brown ironbark.id.au Mira Networking lorikeet.id.au Paul Day wattle.id.au David Keegel wombat.id.au connect.com.au csiro.au CSIRO conf.au Robert Elz org.au Robert Elz 4.3.3 Panel's Single Registry proposal There are a number of disadvantages to the Panel's proposal to tender all open 2LDs to a single registry operator. - It is not clear whether there is an official exact definition of the term "open 2LD", or a list of open 2LDs, adopted by auDA. - Limiting the number of organisations with operational experience of running a registry in the .au space may reduce the competitiveness of the periodic registry tender process. - If only one organisation has significant operational experience of running a registry in the .au environment, they would likely be at a significant advantage in a later tender process - It means going from a situation where there are currently at least 3 or 4 different registries for open 2LDs (depending on exactly how you define "registry" and "open 2LD") to having a single registry. It is not clear that this assists with the introduction of competition, or whether agencies like the ACCC might have something to say about this. - If there was a single commercial registry running com.au, net.au, org.au, asn.au, etc then it is likely that in dealing with that registry auDA would experience the kind of problems which ICANN has had over the last few years with NSI. It would be better to allow the tender process to determine how many separate registries there will be. 4.3.5 single vs multiple registry If the panel wishes to test the registry operator market through a single tender, it may be wiser to make that tender for a single 2LD, rather than a number of 2LDs at once. If there is a requirement for uniform service levels (which is not at all clear - there may be advantages to letting the market provide a range of trade-offs between service level and price, although this is likely to be more an issue in the registrar space), then having requirements set by auDA would likely be a better way to acheive this than letting them be defined by a monopoly player. Because of the monopoly position (or at least special market position) of a registry in a 2LD, there should be a requirement that any domain registration activity related to that 2LD (apart from that explicitly allowed in the registry agreement) would require prior approval by auDA. The reason for this is to deal with the kind of loop-holes which have been shown in the NSI/ICANN gTLD registry contract. Despite considerable effort put into the contract language by ICANN, multilingual domains and registration of sub-domains were effectively outside ICANN's control, as I understand it. Another thorny issue is the control of domains which have expired. It should be made clear that registries and registrars do not gain control of such domains, instead they return to the available pool when they are no longer required by the registrant, so registration organisations cannot resell or auction domains in this way, other than through normal registration procedures. Given these sort of issues and the chance of loop-holes being present in auDA's initial registry contracts, it may be appropriate to require a 2LD registry to have explicit auDA approval for any domain registration activity by the registry (or related entities) in that 2LD, apart from that covered by the registry agreement. 4.3.6 Registry function The core functions of a registry are collision control and maintaining a database of domains. Providing whois service and zone files are other important functions with may also be performed a registry. 4.3.10 Whois data The suggestion of having whois data distributed to registrars has a number of disadvantages. - It raises the barrier to entry for registrars (since they must run their own whois server), which would tend to reduce the number of registrars and therefore reduce competition. - It makes the collapse of registrars a much more difficult problem to deal with, if the authoritative contact details are stored on a server which is no longer operational. - It introduces uncertainty about proprietary rights to data stored by registrars. It must be made clear that whoever stores whois data does not gain any proprietary rights to it. - When data is widely dispersed, it can become more difficult to access