Comments on the Electronic Communications and 
Transactions Bill by Namespace ZA

Draft ECT bill submission - 2002-04-24


Introduction

	Who and what is Namespace ZA?

Namespace ZA is a body established by consent of the Internet userbase in South Africa, at an open meeting 
held on 31 August 2001 in Johannesburg, for the purposes of administering the ZA domain name space. This 
was the culmination of a three year process that was overseen by the local Chapter of the Internet Society. The 
present ZA domain administrator had recognised the need for broader input to policy issues, and for a shared 
responsibility in matters relating to the running and control of the domain name system of the country, and 
therefore approached ISOC-ZA to assist with the transfer of administration.

The three year process can only be described as extremely thorough and open. The persons who served on what 
was called the Drafting Committee had extensive experience with the Internet, and also had extensive exposure 
at international forums to Internet issues, including those relative to the administration of a country code domain 
such as ZA. The documents produced by the Drafting Committee are attached. A section 21 company called 
Namespace ZA is in the process of being registered.

Attached are documents giving details of Namespace ZA's Policies and Procedures, and detailing the philosophy 
relating to the founding of Namespace ZA.

Scope of comments by Namespace ZA

Namespace ZA will limit its comments on the ECT Bill to issues relating to the administration of the ZA domain 
namespace.


It is the firm opinion of Namespace ZA that the 
domain name system of South Africa should be in 
the hands of the Internet community, in 
consultation with government.


Namespace ZA supports the Bill, and in particular 
the objective spelt out in subsection 2(q), and 
wishes to be part of the implementation of the Act 
in due course


In anticipation of this model, the formation of Namespace ZA called for the reservation of at least one of its 
board seats for government participation.

We wish to point out that the Executive Summary arising from the report commissioned by the government from 
Edward Nathan & Friedland, arising from a Green Paper process in April 2001, states the following: -

"The administration of domain names in South Africa has been done to date by a private person on a 
monopolistic basis without a regulatory framework within which to ensure good and non-discriminatory 
practices. This is not to say that the system has been discriminatory or not good in the past, it is simply 
to say that with the next wave of explosive growth of the Internet, that we should expect if the barriers 
to electronic commerce] are successfully removed, a system should be in place to ensure the required 
standards. Ultimately, this may require no more than a policy statement by the 
government within which a private system should operate. More study and 
consultation in this regard is necessary." [Our emphasis]

Namespace is not aware of any such consultation process. Further, neither the present ZA administrator nor, to 
the best of our knowledge, any other second-level domain administrators were consulted or even informed of 
this recommendation.

Also, the Memorandum at the end of the ECT Bill states this about Chapter X: -

"A section 21 company will be established, or an existing one approved, to manage the 
domain name space of the Republic." [Our emphasis]

Namespace ZA would welcome government approval of an existing Section 21 company as contemplated in the 
Memorandum. Unfortunately, it would appear that this possibility was accidentally omitted from the text of the 
Bill.
[More on subsection 2(q) and comment about respect for cultural values.]

Models of ccTLD Administrations

In order to assist the Parliamentary Portfolio Committee on Communications, we have made a classification of 
currently used models of ccTLD administration around the world (for an extensive list, see ANNEXURE A: 
Government Involvement in ccTLD Administration and ANNEXURE B: Table of Government Involvement in ccTLD 
Administration, both available on http://www.namespace.org.za). The classification is: -

1)	Government acknowledges the existing ccTLD administration, but doesn't create any formal 
legislation (this is an informal approach, and is adopted by most countries).

2)	Government makes some legislative provision for the potential future creation of namespace 
regulations, but leaves the existing ccTLD admin to do its job (for example, Ireland's IE domain).

3)	Government creates legislation recognising/empowering the existing ccTLD administration, but 
takes a hands-off approach on the details (more formal approach adopted by some countries).

4)	As above, but with a legislative clause allowing the government to take over should the existing 
ccTLD administration fail (for example, Australia's AU domain, and others).

5)	Nationalise the operation of the ccTLD (for example, Finland's FI domain, where this process 
took place with the support of the Finnish Internet community and ISPs).


Namespace ZA's strong preference is outlined in 
model 3. Second choice would be any of models 1, 2 
or 4.

 It appears that the drafters of this Bill intended to 
create legislation consistent with model 3 
(recognising the existing ccTLD administration), 
but in fact the result is closer to model 5 
(nationalising the ccTLD administration).  The most 
important changes required to correct this problem 
would be to reinstate the option for approval of an 
existing section 21 company, and to move some of 
the power from the Minister to the Domain Name 
Authority.

Namespace ZA is of the firm belief that there is a 
need for some kind of government involvement in 
the administration of the ZA domain space, but not 
to the degree that is prescribed in the bill.


Other discussion points on the general approach

The bill impacts severely on the independence of the Domain Name Authority of Chapter X. It empowers the 
Minister to make regulations regarding the domain name system of the country, which can readily impact 
adversely on the functioning of this key aspect of electronic commerce. The drafters of the bill have shown a lack 
of technical understanding, the result of which impacts on the implementation of this Chapter.

The administration of a domain such as ZA has wide ramifications. The correct functioning of the ZA domain is 
an absolute requirement in order for a sub-domain such as CO.ZA to function, which itself is an absolute 
requirement for an end-user domain such as COMPANY.CO.ZA to function, likewise for sub-domains of ZA such a 
MIL.ZA and GOV.ZA. Thus there is a basic requirement for much more consultation with the Internet community 
and industry. The proposed legislation was formulated with ABSOLUTELY NO consultation with the present 
administrator of the ZA domain, and with no input from domain name experts or the local Internet community.

It is extremely critical to ensure continuity of existing registration procedures and operation, or the Internet in 
South Africa will collapse. The current legislation runs the risk of forcing all registries to stop operation, bringing 
the ZA domain name system to a halt. The seriousness of this need for continuity, and consequences of getting 
things wrong, cannot be overemphasized.

There is a further matter. A body with the name of ICANN, as set up by the US government, controls what is 
called the "root" domain, which is the parent domain from which country code domains such as ZA are 
established. There are some ICANN rules, which must be adhered to, and procedures that must be followed for 
the administration of a country code domain to be redelegated from one authority to another. If this does not 
happen, then it matters not what laws are made in a country such as South Africa, the redelegation of the ZA 
domain will not take place.

As far as ICANN is concerned, there is a specific set of specifications that must be met in order for a change in a 
ccTLD administrator to be accepted. The change process itself is a function of IANA, the Internet Assigned 
Numbers Authority. The specifications are spelt out in the following documents that are available on the web at

RFC 1591 (March 1994) [http://www.isi.edu/in-notes/rfc1591.txt]

IANA ccTLD Delegation Practices Document (ICP-1) (21 May 1999) [http://www.icann.org/icp/icp-1.htm]

An extract from RFC 1591 reads: -

4) Significantly interested parties in the domain should agree that the designated manager is the 
appropriate party.

The IANA tries to have any contending parties reach agreement among themselves, and generally takes 
no action to change things unless all the contending parties agree; only in cases where the designated 
manager has substantially misbehaved would the IANA step in.

However, it is also appropriate for interested parties to have some voice in selecting the designated 
manager.

An extract from ICP-1 reads: -

In the event of a conflict over designation of a TLD manager, the IANA tries to have conflicting parties 
reach agreement among themselves and generally takes no action unless all contending parties agree. 
On a few occasions, the parties involved in proposed delegations or transfers have not been able to 
reach an agreement and the IANA has been required to resolve the matter. This is usually a long drawn 
out process, leaving at least one party unhappy, so it is far better when the parties can reach an 
agreement among themselves. It is appropriate for interested parties to have a voice in the selection of 
the designated manager.

It is clear that there is a requirement for consultation and support from the local Internet community before any 
redelegation will take place. This consultation has not taken place, due to no fault of the present ZA domain 
administration nor of the Internet community, and the support of the local Internet community as represented by 
Namespace ZA will not be forthcoming for the proposed legislation in its present flawed form.

A Matter of Enforceability

We wish to point out in the clearest terms possible that 
South African legislation is capable of preventing the 
present ZA administration from functioning, but is not 
capable of compelling any action on the part of any non-
South African entity, and in particular is not capable of 
compelling IANA to reassign the ZA administration to any 
specific entity or person. The consequences of such 
legislation will be that every last Internet address that ends 
in .ZA will vanish out of the Internet, including all 
subdomains of CO.ZA, GOV.ZA, MIL.ZA, AC.ZA, etc.



Detailed comments on the Bill

Definitions


While acknowledging the necessity to have various technical terms defined in terms of an Act of Parliament, 
there is nevertheless another necessity, viz to have those term defined such that they are close to common 
usage by experts in the field. In this Bill, there are definitions that are far removed from such common usage. 
Disputes relating to the usage of these terms may well end up in court, requiring expert witnesses to apply their 
interpretation and to clarify issues relating to the use of these terms. It will lead to all kinds of confusion and 
difficulties if those experts have to use the words of their language in a significantly different way compared to 
normal usage, and this will not help the cause of justice. We feel obliged to point out some of these bad 
definitions.

We fully recognise the need to do more than snipe at broken definitions, and rather to try to fix them. In a few 
cases we have done so, but there can be an impact on the wording of legislation, so this is not to be done 
lightly. We are willing to assist with the redefining of the technical definitions in the bill, if the committee so 
wishes.

ccTLD: This is badly worded, and we suggest a rewrite: 

"ccTLD" means a country code domain at the top level of the Internet's domain name system, assigned 
according to the two letter codes in the International Standard ISO 3166-1 (Codes for Representation of 
Names of Countries and their Subdivisions)"

domain name and domain name system: The definitions are very woolly. They need to be replaced. The 
definitions are also too narrow, and describe only a subset of the actual domain name system. The definitions 
need to match internationally accepted definitions to avoid confusion with expert witnesses.

E.g., a domain name such as COMPANY.CO.ZA does not, in general, describe an "electronic address", but rather 
it specifies an authority that can assign domain names to the computers of COMPANY, such as, for example, 
COMPUTER1.COMPANY.CO.ZA. Within the Internet's domain name system, it is correct to use the term "domain 
name" both for the "parent" domain COMPANY.CO.ZA as well as to use the same term for the name of the 
computer, viz COMPUTER1.COMPANY.CO.ZA – both of these are "domain names", yet only the latter must have 
an IP address, and the former might or might not have an IP address.

E.g., the ccTLD "ZA" is itself a domain name, and it most certainly does not represent nor convey any concept of 
an electronic address as it is currently configured. It would require a very broad definition of the term "address" 
in order to treat all domain names as "addresses".

electronic: The definition is both too narrow and too broad.
E.g., there are analogue (as opposed to "digital") electronic signals that are part of voice, and voice is part of the 
definition of "data message".

E.g., there are many intangible things that are not "electronic" by any stretch of the imagination, e.g. a thought 
is intangible, a colour such as green is intangible, but no one would consider these to be "electronic".

electronic agent: What does "used independently" mean? Independently of what?

ICANN: "in terms of the laws of the state of California". This needs to state that California is in the USA.

Internet: This is a very poor definition indeed, as it does not convey the complexities of the Internet as 
perceived by experts on the matter. It should be reworded completely. We suggest the following wording: -

	(The) Internet means the global system of interconnected networks that uses the TCP/IP protocol suite

E.g. "future versions" of what? Does this mean future versions of the TCP/IP protocol suite, or of the Internet 
itself? (This latter interpretation is then recursive, which is undesirable)

E.g. This definition could include private TCP/IP networks, which aren't part of the Internet. The definition as 
worded in the Bill is that of "an internet" not "the Internet". The spelling of internet with a lowercase "i" 
describes any private interconnection of networks that use the TCP/IP protocols, but when spelt with a capital "I" 
it represents the single world-wide such interconnection. This definition covers all (lowercase "i") internets, 
whereas it is likely that the intent was to cover only the (capital "I") Internet.

IP address: This definition is too broad, and is inaccurate by any standards. The term "data message" cannot 
be included in the definition, because by no stretch of the imagination does an IP address identify voice nor 
stored records. An IP address also conveys absolutely no concept of "location" as conveyed in the proposed 
definition. It would require a suitably broad definition of the term "location" for this to be so.

person: "'person' includes a public body" -- what about private bodies?

registrar: Needs to specify "the Domain Name Authority of Chapter X".

registry: Should specify "the Domain Name Authority of Chapter X". Depending on the definition of sub-
domain, this definition may need to be modified. See comments under the definition of sub-domain. The Domain 
Name Authority needs to treat sub-domains such as CO.ZA and MIL.ZA differently to those of WITS.AC.ZA, 
EE.WITS.AC.ZA and COMPANY.CO.ZA.

Suggestion: The definition of Authority should be split into two definitions, one for "Accreditation 
Authority" and one for "Domain Name Authority", and all references to Authority should be changed 
to refer to the relevant authority.

second level domain: What about second level domains that do not signify a category or type?

The definition should read:-

"second level domain" means a sub-domain immediately under the ZA ccTLD.

It is the opinion of Namespace ZA that this definition in the Bill is badly broken, and that legislation should not 
redefine common terms like this!

sub-domain: How deep does this definition go? Does it extend right down to 
COMPUTER34.ODIE.EE.WITS.AC.ZA? If so, the consequences are quite serious, it means for example that within 
an organisation the Domain Name Authority of Chapter X has sway, and that Wits itself does not control the 
namespace of its departments, they are controlled by the Authority. In this example, it is within Wits University, 
but the argument extends to COMPANY.CO.ZA, DEPT.GOV.ZA, etc. This is clearly ridiculous and unacceptable.

In addition, there are circular references between "sub-domain" and "second level domain", with each of these 
being defined in terms of the other.

TCP/IP: This definition has a circular reference to "Internet" and "information system".

Further, TCP/IP could mean the TCP and the IP protocols or it could mean the TCP/IP suite of protocols. Does it 
make any sense to even use the term TCP/IP for other definitions?

Note that the "Transmission Control Protocol" and the "Internet Protocol" are two distinct protocols, providing 
different aspects as to how computer systems communicate across what is loosely termed "a TCP/IP network". 
There are many other protocols as well, like UDP (User Datagram Protocol), SMTP (Simple Mail Transfer 
Protocol), HTTP (HyperText Transfer Protocol), FTP (File Transfer Protocol) and very many more. Generically, 
these are termed "the TCP/IP protocol suite". The Bill does not distinguish when it refers to TCP/IP meaning 
literally the two protocols (TCP, IP) and the all-embracing suite of Internet protocols.

TLD: TLD means "a top level domain", not "the top level domain".

web page: This definition has a circular reference to "data message".

web site and world wide web: These definitions are incredibly broad. They incorporate all kinds of content 
which actually has *nothing* to do with web services. As it stands, this would include private content on 
computers and even password files! And what is "an Internet hyperlinked distributed information retrieval 
system" anyway?

.za domain name space:  According to <IANA policy> read in conjunction with ISO 3166, the ZA ccTLD is 
reserved for the geographic area of the Republic. This is very different from being assigned to the Republic.

Part-by-Part Comments on Chapter X

Part 1: Establishment and incorporation

General

We believe firmly that the legislation needs to provide for alternatives to forceful nationalisation. Such 
alternatives were discussed in the introduction above.

The issues relating to the transfer of control to a new body from the existing ccTLD admin, and to getting 
approval from ICANN for a redelegation, must be covered, but are not. The Bill lacks any provisions for the 
transfer of the control of the ZA name space.

Redelegation requires an ICANN contract. Thousands of dollars will be required to make this happen.

It can, and indeed may, be argued in due course that the existing administrators of ZA and its sub-domains have 
certain rights. There is therefore a potential issue of expropriation, which is not dealt with at all.

If the proposed legislation causes hiccups in the 
administration of the ZA domain, then people will 
just start registering domains elsewhere. It does 
not create a good impression when one sees 
domain names like such as GAUTENGONLINE.COM 
for the Gauteng Online school networking project.


Specific

Section 60 (Establishment of the Authority): The summary at the end (i.e., the Memorandum) indicates quite 
clearly that the government will either establish a new Section 21 company, or will approve an existing one. We 
welcome this approach, but this concept does not appear in the main text! This is a bad inconsistency, and we 
have referred to this in our introduction. We repeat our preference that this be incorporated into the legislation, 
with a provision that the Government '"take over" if things go badly wrong (with appeal mechanisms etc as in all 
good laws).

Section 61 (2) (The State as the only Member): This is wholly unacceptable for an organisation purporting to 
reflect the interests of the Internet community. The State could (we feel "should") be *one* of the members of 
the organisation. Registrars, registries and other members of the Internet community should have a mechanism 
for representation, as well as interested parties who are not yet part of that community. The Domain Name 
Authority should not be exempt from the provisions of the Companies Act. -- Even *if* government were to 
nationalise, we regard these are unacceptable provisions.

Section 62 (2) (Ministerial control): Likewise, this is unacceptable, and for the same reasons given above. We 
can see no justification for moving away from the normal model for a Section 21 company.

Section 62 (4) (Memorandum and Articles): We feel that this should not be dealt with in legislation, but rather it 
should be dealt with in regulation, or by negotiation with the parties involved in the Authority.

Part 2: Governance and staffing

General

There are some serious problems with the proposed legislation, especially in the proposed make-up of the 
stakeholders. What is the situation with regard to, say, a disabled Internet worker in the business community? 
Does such a person qualify under (i) the Internet community, or (ii) the business community or (vi) the disabled 
or (viii) civil society? Or under all of them? Or under none of them? How is this determined? How is "civil society" 
represented, and how does it make its nominations?

The Namespace ZA model is far more inclusive, and allows membership of the organisation by all persons who 
have control over a domain (e.g. the administrator of COMPANY.CO.ZA), the various registrars of second level 
domains, and any interested party willing to pay a nominal fee to cover administration costs.

There are two main areas of ccTLD activities, viz (1) technical, and (2) policy making; while many stakeholders 
may need to have input into policy, the technical operation is more critical and needs technical expertise rather 
than broad representation. This is not catered for in the Bill.

The ccTLD administration needs some staff with DNS expertise, this is not adequately provided for in the 
proposed legislation.

The Namespace ZA model is a very thin model, keeps staffing costs to a minimum, is self-funding, and places no 
financial burden on the taxpayer. By way of contrast, the ECT proposal is fat and expensive.

Specific

Section 63 (1) (Board of Directors): There can be up to 16 Directors on the Board. This number is extremely 
large and unwieldy. We feel that there is no need for more than six or seven Board members, and we suggest 
six plus the CEO. (This also reduces costs were the Board members to be remunerated.)

Section 63 (2)(Board of Directors): Most of these groups are just not relevant to the Internet. This is not an 
appropriate method for the election of the board. There should be an election by the members, not arbitrary 
appointees by the Minister. There is nothing to suggest that the objectives in the Green Paper report, as quoted 
in the introduction, will be met by such a Board.

Further, the election process should be defined in the Articles of Association, and not in legislation/regulation. 
We believe that it is quite practical that an election can be conducted by suitable means (electronic, postal, 
whatever). Elections can be managed even if the membership is large. The justification for our viewpoint is the 
benefits of the alternative macro models as presented in the introduction.

Section 63 (5) (Board of Directors): We feel strongly that the members should determine the board, and that this 
is not the prerogative of the Minister.

Section 64 (Disqualification of Directors): This is dealt with in the Companies Act, so there is no need to include 
it here. 
Section 65: We challenge that the Directors of the Board should be remunerated. The proposals in the Bill allow 
for remuneration, and this contrasts markedly to the present administration, and to the way that the Internet has 
evolved. Even if our viewpoint is not supported, this matter is one that should be included in the Articles and not 
entrenched in legislation.

Section 67 (Staff of Authority): This should also be in the Articles, and not in legislation, for the reasons given 
above.

Section 67 (2) (Staff of Authority): Change "must" to "may", so that this reads:-

"67(2) The chief executive officer may be assisted by staff appointed by the Board."

Part 3: Functions

General

We wish to highlight a very serious problem: the proposed legislation, in effect, gives ICANN a blank cheque. 
Given the recent statement from the ICANN President & CEO that ICANN is not functioning, this is very 
dangerous. ICANN has also sent invoices to the current ZA administrator (which have been rejected) for totally 
arbitrary amounts for completely undefined "services".

There is also a possibility that the ccTLD functions of ICANN become separated from the generic functions of 
ICANN. Were this to happen, the "successor or assigns" of ICANN would still be ICANN, and the law would have 
to change in order for ZA to follow the rest of the world in dealing with another entity. Otherwise, this would 
require the Domain Name Authority to act illegally, or the ZA domain name space would crash in its entirety.

In regard to the instability within ICANN, and how ICANN is being received generally by the Internet community, 
we refer to an article (it is but one of many) entitled "ICANN under fire – again" taken from 
http://zdnet.com.com/2102-1105-87132.html, which is attached as ANNEXURE C. We draw attention 
to the very first paragraph which states:-

"Lawmakers are calling for hearings, consumer groups are up in arms, and directors [of 
ICANN] are attacking each other in increasingly nasty ways."

This is not a new situation, ICANN has not had the respect of the Internet community since soon after its 
inception.

Apart from the ICANN issue, the Bill has no provision for any technical functions or operation. Adherence to good 
technical standards is very important; indeed it is essential, for a ccTLD Administration.

The proposed legislation gives the Minister absolute power over almost everything to do with the ZA name 
space. This is not a healthy approach, and may well be open to challenge in the highest courts of the land.

If the above aspects are rejected, then there should be a requirement for the policy makers, including the 
Minister, to pay attention to representative input.

Specific

Section 68 (1) (Licensing registrars and registries): "No person may update a repository or administer a sub-
domain". With the existing definition of sub-domain, this leads to a requirement for the administrator of  each 
and every COMPANY.CO.ZA to be licensed. More, it means that whoever administers a domain such as 
PARLIAMENT.GOV.ZA must also be licensed, because in both cases these persons act as registries. Given that 
there are more than 100,000 sub-domains of CO.ZA, and who knows how many GOV.ZA and MIL.ZA sub-
domains, this becomes a nightmare. If the response is that the Domain Name Authority can do a "blanket freebie 
licensing" of such domains, then why have these provisions in the legislation in the first place?

Perhaps it would be appropriate to change "sub-domain" to "second level domain" for this clause.

Also, the term "licence" is inappropriate, the Internet uses the term "delegate", which is standard terminology for 
the administration of domain names.

However, making legislation in this field is full of problems. What about situations where there is a need to have 
some sort of control over more than the second-level domain. e.g. Whoever administers SMITH.NOM.ZA must 
carry some specific obligations to the Domain Name Authority, so that it is possible and simple for John Smith 
and Jack Smith to register the domains JOHN.SMITH.NOM.ZA and JACK.SMITH.NOM.ZA. These issues, we 
suggest, are best left to an industry-elected body to deal with, and not to legislation.

Section 68 (1) (Licensing of registrars and registries): It is not specifically made an offence to operate without a 
licence. What are the consequences if someone ignores this provision?

Section 68 (2/3) (Prescribed issues): There is no appeal mechanism against what is prescribed. The prescribed 
matters, manner, conditions and criteria are determined, apparently, by the Minister as per section 72, without 
any provision for any consultation. We submit that this is not good for the Internet, apart from not being good 
procedure. There is also a need for a rapid mechanism for appeal if the Domain Name Authority does something 
wrong

Section 69 (1) (a) (Functions of Authority): It is not specifically stated that the Domain Name Authority has the 
right to outsource certain functions, and we believe that this should be done.

Section 69(1)(b) (Functions of Authority): We believe that it is essential to remove any reference to ICANN! 
ICANN is a private US corporation, there should under no circumstance be legislation binding South Africa to 
such an entity. Our suggested wording is:-

69(1)(b) comply with the requirements for administration of the ZA domain name space having regard to 
accepted international best practices and standards."

Section 69(1)(d) (Functions of Authority): It may not be necessary to license all registrars - what about a self-
registration process for some sub-domains? There needs to be provision for this.

Section 69(e)(Functions of Authority): The word "guidelines" seems more like advice, which in itself is not a 
problem. However, the Domain Name Authority needs to be able to set "requirements" (mandatory) and 
"guidelines"(optional). 

Also, the legislation fails to deal with the idea of a charter for a second-level domain – which appears to be a 
definite oversight. A charter for a domain defines such things as who it eligible to register a sub-domain in that 
domain, and controls to a large degree the duties and powers of the administrator of the domain.

Section 69 (2) (Functions of Authority – enhancing public awareness etc): This is *not* the function of a Domain 
Name Authority. Promoting the Internet is a function of commercial entities. We propose that "must" be changed 
to "may", so that this reads:-

(2) The Domain Name Authority may enhance public awareness on the economic and commercial 
benefits of domain name registration.

Section 69 (3) (b) (Functions of Authority - research): This is very vague as an obligation, it would be better to 
change "must" to "may".

Section 69(3)(c) (Functions of Authority – survey): As above, change "must" to "may". In addition, "continually" 
is superfluous and means instant by instant, which cannot be done even were it intended. Further, the word 
"citizens" is too restrictive, should also include "residents" and other users of the domain. E.g., it may well be 
that it is advantageous to earn FOREX by registering ZA domains for entities in other countries, in which case the 
Domain Name Authority must look much wider than the citizenship of South Africa.

Section 69 (3)(d) (Functions of Authority – issue information). As above, cater for a wider need should this 
happen, and also don't write legislation that will affect domains such as those under .COM, .NET etc. Reword this 
paragraph to read:-

69(3)(d) may, from time to time, issue information on the registration of ZA domain names.

Section 69 (5)(Functions of Authority – measure effectiveness): This has bad wording. Replace with:

69(5) The Domain Name Authority should regularly evaluate the effectiveness of Chapter X of this Act.

Section 69 (6)(Functions of Authority): We suggest that there should be provisions to outsource some of the 
functions of the Authority, and that this needs to be clearly stated in the Bill.

Section 69 (7)(Functions of Authority – upholding of vested rights): Again, the sub-domain problem raises its 
head. As it stands, all sub-domain owners are forced to apply for licences. This section needs to be limited to 
second-level domains

There is no explicit provision for legacy domains, which were established before a clearer ZA policy emerged. 
These represent the efforts of the early pioneers of the Internet in South Africa, and include domains belonging 
to De Beers and Olivetti, to mention but two of them. Their rights need to be respected.

Also, parties should not be *obliged* to reapply -- perhaps they don't want to because, say, this legislation is not 
giving them due respect or for any other reason. So, in 69(7)(b), "must" should read "may", and in "registrars 
and registries" change "and" to "and/or".

In addition, we point out a contradiction – existing domain name holders can continue with the status quo for six 
months, and only after six months (i.e. not before) can someone apply to fit in with the new regime. It seems 
likely that the intent is for existing domain name holders to submit applications before the end of the six month 
window, but that's not what the words say.

Further, it is not at all clear when the timing of the six months starts? E.g., is it from the promulgation of the Act, 
or from the registration date of the new Section 21 company, or from the appointment of the chairman of the 
Board of the Authority, or from the date of the first meeting of the Authority, or when?

We also query whether six months will be long enough, and feel that there must be provision to extend this 
period (no matter from when the clock starts ticking).

There is no provision here for the transfer of the ZA domain itself, because only sub-domains are covered here. 
We feel that this is a most serious omission.

Part 4: Finances and reporting

General

There is an issue as to whether the administration of the ZA name space should be funded by the taxpayers or 
whether it should be self-funding: Most independent ccTLD admin organisations are self-funding and efficient. A 
government operated organisation would require money from taxpayers to operate. Namespace ZA is of the firm 
opinion that the entity should be self-funded.

There must be accountability back to the people who provided the money for the administration of the ZA 
namespace. The Namespace ZA model has this, the Bill as worded does not, and this is to be regretted.

Most of these points are covered in the Companies Act and trying to duplicate them here would lead to confusion 
and uncertainty

Specific

Section 70 (2)(Finances of Authority): Setting the financial year in legislation seems heavy handed. This should 
be a matter for the board to decide on as per normal statutory process.

Section 70 (4) (e) "sale of assets" what is to stop the organisation from selling its database to spammers? This 
clause should be restricted to "tangible assets"

Section 70 (6) (a): There is a reference to a "statement of the Authority's estimated income and expenditure" 
contemplated in subsection (4), this should read "subsection (7)".

Section 70 (7) (c): "referred to in paragraph (a)" should be "paragraph (a) and (b)", otherwise the Domain Name 
Authority can't spend the money referred to in paragraph (b).

Section 71 (Reports): The report should be made public, and not just submitted to the Minister. The issue of 
administering the ZA namespace is a matter of public concern, and is not a matter of concern only to the 
Minister.

Part 5: Regulations

General

Namespace ZA regards it as a most important issue that cultural names need protection, and any dealing with 
them should involve the government, as the protector of the country's heritage. This is in line with the proposals 
that led to the establishment of Namespace ZA.

There is a definite need for government to be able to make input on ccTLD policy. The proposed Namespace ZA 
model provides a clear and well-defined mechanism for this input, in a way that we consider to be superior to 
the provisions of this Bill.

The majority of these issues are technical or operational, and it would therefore be inappropriate for the Minister 
to regulate them. We believe that consultation with the Minister would be appropriate in matters of policy.

Specific

Section 72 (Regulations regarding Domain Name Authority): Where regulations are necessary, the Domain Name 
Authority should be the party making the regulations. However, we contend that it is not necessary to regulate 
all of the issues set out in Section 72, many of which would be better dealt with by the Domain Name Authority 
as internal procedures. For the development of any regulations, there needs to be a consultative process, 
including taking full cognisance of the work of international bodies such as the IETF (the Internet Engineering 
Task Force) and local organisations. We have indicated our preferences below.

Section 72 (a)(Requirements and standards for registries): The Minister should not make these regulations, it is 
not appropriate for Internet standards to be laid down by a Minister. These are highly technical standards, set by 
existing Internet organisations, such as the IETF. They should be set by the Authority, which itself should have 
technical experts on its Board.

Section 72 (b)(assigning, registering, renewing, refusing, revoking registries): The Minister should provide input 
on the cultural issues, but the Domain Name Authority should handle the more general circumstances and 
manner of registrations.

Section 72 (c)(pricing) and (d)(restoration and penalties): The Domain Name Authority should handle these; it 
should not be done at the dictates of any Minister.

Section 72 (e)(Terms of registration agreements): The Domain Name Authority should handle this, but bearing in 
mind that there is existing consumer protection law. Alternative dispute resolution should be removed from this 
section, since it is already covered in Part 6.

Section 72 (f)(unfair and anti-competitive practices): The Domain Name Authority should handle this, but again 
there is existing law dealing with unfair and anti-competitive practices.

Section 72 (g)(admin and technical contacts for a domain): Neither the Domain Name Authority nor the Minister 
should handle this. It is dictated by existing Internet standards, laid out quite clearly in documents known as 
RFCs (Request for Comments).

Section 72 (h)(creation of new subdomains): Apart from this not being a matter for a government Minister, but 
rather a matter for the Authority, the word "sub-domain" should be "second-level" domains. As worded, the 
Minister would be allowed to make regulations that control domains like ODIE.EE.WITS.AC.ZA, which is by any 
Internet standards and practices a matter for Wits University to handle, and similarly for every other third and 
lower level domain.

We restate the principle that every second-level sub-domain of ZA should have a charter, and it is this charter 
that would impose regulations on its sub-domains.

On certain domains, there should also be a process of public input on this issue.

Section 72 (i)(monitoring and compliance): Firstly, the wording should be "compliance with the provisions of this 
Chapter of the Act and the...".

Then, we are of the firm opinion that this is quite clearly a matter for the Domain Name Authority to handle, 
because this issue is highly technical.

Section 72 (k)(policy): This may fall away if there is a split of functions between the Domain Name Authority and 
the Minister. However, as worded, this opens the door to a conflict between technical requirements for domain 
administration and the views of the Minister with regard to policy matters.

Part 6: Alternative dispute resolution

General

We suggest that the title of this Part should be "Dispute Resolution", rather than "Alternative Dispute 
Resolution". Any dispute resolution process needs to be precedent setting. A ruling made under any particular 
set of circumstances must be replicated if the same or similar circumstances apply to a subsequent situation.

ADR should be an option for potential registrants/litigants, but not a compunction. A mechanism of determining 
the rules as to when the ADR can/will apply needs to be defined.

Specific

Section 73 (1)(making regulations for ADR): We suggest the following wording: -

 The Minister, in consultation with the Ministries for Justice and for Trade & Industry, must make 
regulations for a mechanism alternative to litigation for the resolution of disputes in respect of contested 
domain names within the .ZA domain name space.

Such mechanism shall not exclude any party from approaching the courts for relief in appropriate 
circumstances.


Section 73 (3) (b)(the Authority's role in ADR): The Authority should absolutely NOT be involved in the dispute 
resolution process, because we feel that the Domain Name Authority must be independent. Change to "the 
Domain Name Authority must play no role in the ADR process". Having the administrator of a domain involved in 
the ADR process also opens up a whole can of worms regarding legal liability.

Comments on other chapters that we feel will impact on Domain 
Administration

Chapter V: Cryptography Providers


A "cryptography product" is defined far too broadly, and includes concepts that even the layman would not 
describe as being cryptographic. In general, encryption causes clear-text to become unreadable encrypted text, 
and is not a mechanism for ensuring data integrity. Specifically, definition part (c) "ensuring the integrity of the 
data" causes a simple checksum or even a parity check or a word count to be defined as a cryptography product. 
Thus, as currently defined, the *whole* of the TCP/IP protocol suite could be classed as a cryptography service, 
because checksums are used in both the TCP and the IP protocols in order to ensure data packet integrity. In 
this case, no one would be able to provide any Internet services without being registered as a cryptography 
provider.

[Note that Webster's Third New International Dictionary has this to say about "cryptography":-
1. secret writing
2. the art or practice of preparing or reading messages in a form intended to prevent their being read by 
those not privy to secrets of the form; also: the science of devising methods and means for this.

There is nothing about "data integrity".]

This section could also have an unintended and a seriously detrimental impact on domain name services -- in 
particular DNSSEC, which is designed to ensure integrity within the domain name system.

This chapter needs to be amended so that it does not apply so broadly, and it must definitely exclude the CRC 
checksums of TCP and IP. We recommend the deletion of paragraph (c) of both the cryptography product and 
cryptography services definitions.

Chapter VIII: Protection of Personal Information

The requirements for the protection of personal information clash directly with the operation of the domain name 
system's "whois" services. However, given the voluntary nature of the chapter, this may not be a serious issue. 
However, there is confusion of a possible conflict of interpretation between clauses 51(2) and 51(3). It is 
possible to interpret 51(3) as compelling a data controller who, say, complies with 52(1) and gets express 
written permission from a data subject to also meet every clause of section 53 as a result of having got such 
written permission.

Clarity is need on whether this chapter *is* actually voluntary!

If indeed it is voluntary, then there is surely no need to have this entrenched in legislation, but should rather be 
left to a standards body, or an industry association, to deal with.

Specifically, a domain name administration body would not be able to comply with 52(7). It is not possible to 
determine nor verify with the slightest accuracy who accesses a whois server, nor the purposes for which such 
access was made.

Chapter IX: Protection of Critical Databases

There is potential for one or more name space databases to be declared as critical databases. This could have 
serious unintended consequences, including:

Section 55(1)(c) and 56(1)(a)-(f): The Minister will be empowered to prescribe arbitrary standards/prohibitions 
for critical databases. These standards may clash with Internet standards, and consequently might cripple the 
domain name services in South Africa. The Minister should not have the powers, nor be put in a position, to 
break the Internet in this manner.

Section 57(1): Restrictions on the disclosure of information contained in the register of critical databases may 
conflict with the IANA/ICANN requirement that the details of the .ZA administrator be published publicly. Perhaps 
the intent is that if the only source of the information is in the proposed register, then and only then it may not 
be disclosed, but as worded if, say, the ZA database is declared to be a critical database, then the name and 
contact information of the controller of that database may not be disclosed to any third party by anyone.

Clarity is needed on the intention of the section of confidentiality of the register of critical databases. Limiting the 
publication of information in a domain name database on the grounds that it is a critical database will defeat the 
purpose of the domain name system.

Section 58(1) This clause is grammatically incorrect: audits cannot be performed "at a critical database 
administrator".

Section 58(1) We are very concerned that the Director-General will be given unlimited power to impose audits 
arbitrarily, without having to justify why this is being done, and being accountable to no one whatsoever. At the 
very least, there should be some requirement for "reasonableness".

Section 58(2) There is a critical need for technical competence and independence in anyone performing database 
audits. This is missing from the Bill.

Section 59(1)(b)(Action required to remedy a problem): What if the action required for remedy will wreck the 
Internet's domain name system? There is no requirement of proof that the audit is indeed accurate in what it 
reveals, so there should be some mechanism for appeal. When dealing with Internet issues, Internet standards 
need to have a high priority and should not be set aside unilaterally by the Director-General or by anyone not 
highly competent in Internet matters.


Submission by Namespace ZA regarding the Electronic Communications and Transactions Bill
Page 1 of 17 pages