Comments on the Electronic Communications and
Transactions Bill by Namespace ZA
Draft ECT bill submission - 2002-04-24
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.