[Date Prev]   [Date Next]   [Thread Prev]   [Thread Next]   [Date Index]   [Thread Index]


Comment ccNSOAG3: Nominet .UK
  • To: <reform-comments@xxxxxxxxx>
  • Subject: Comment ccNSOAG3: Nominet .UK
  • From: "Gloria Mundy" <gloria@xxxxxxxxxxxxxx>
  • Date: Tue, 19 Nov 2002 09:09:44 -0000
  • Importance: Normal
  • Reply-to: <gloria@xxxxxxxxxxxxxx>

Please find the comments from Nominet .UK - appended below as text.

Dr W Black
Executive Chairman
-------------------------------------------------------------------------
Nominet UK Public Position Statement on the Preliminary Recommendation on
Policy-Development Process by ICANN's ccNSO Assistance Group.

Nominet UK, the national registry for .uk domain names, is grateful for
the opportunity to comment on the preliminary recommendations on the
policy development process, as published by ICANN's ccNSO Assistance
Group on 11 November 2002.

As a preamble, Nominet fully endorses the decision made by members of
the country code Top Level Domain (ccTLD) Registries at the last ICANN
meeting in Shanghai to withdraw from the Domain Name Supporting
Organisation (DNSO) in order to explore alternative ways of managing the
IANA function and, more generally, the interests of the ccTLD community.

As to the preliminary recommendations, Nominet cannot comment in detail
on many of the points within the document, as it is in substantive
disagreement with the principles that appear to be behind them. Nominet
has therefore set out its position below:

1. The preliminary recommendation appears to set no bounds on what
policy can be made. Nominet does not recognize ICANN or its various
actual and putative supporting organizations as an appropriate or
legitimate vehicle for determining Nominet's own policy, or indeed the
policy of any other ccTLD manager. Specifically the remit of an advisory
organization to ICANN should be limited to advising ICANN on ICANN's own
policy toward ccTLD managers. If ccTLD managers require their own policy
advice, they should obtain it elsewhere as they see fit. Nominet
distinguishes this from the sharing of best practice between ccTLD
managers, which, as stated below, it considers important, and Nominet
accepts that ICANN might have a useful role to play in this respect.
Each ccTLD manager needs to develop its own policies according to local
laws, customs, and regulatory and business environment, as  well as the
demand for registrations. The requirement for this can be seen by the
diversity of policies amongst the current ccTLD registries: compare, for
instance, the policies Nominet (running the UK registry) and AFNIC
(running the French Registry). Whilst Nominet can convincingly argue,
with respect to the UK, that it has the best and most appropriate
policies, it cannot argue that those policies are thus necessarily
appropriate for France. Undoubtedly the converse is true with respect to
AFNIC. Hence policy of ccTLD operators should, as per RFC1591, be
determined in consultation primarily with the local internet community,
rather than ICANN or other ccTLDs. Many ccTLD  managers already have
effective mechanisms of determining their own  policies in this way. For
instance, Nominet maintains a Policy Advisory Board to provide advice on
the development of policy to its Council of Management, and act as a
conduit for consultation with Nominet's various stakeholders. Its
membership comprises two non-executive directors of Nominet,
representatives of up to five appointed organizations, plus eight
Nominet members who are elected by Nominet's own membership (i.e. the
industry). The appointed organizations provide representatives of
government, industry organizations, consumer bodies, and the
intellectual property constituency.

2. The proposed structure adds unnecessary layers of procedure,
bureaucracy and expense. ICANN, as the current IANA operator, should
bear in mind that IANA's function with respect to ccTLDs should be to
record the details of the nameservers within the root zone file, to
change these on the instruction of the designated ccTLD manager, and to
publish the root zone file to root server operators. In respect of
ccTLDs, there is no requirement on ICANN to exceed these simple IANA
functions. Maintaining a database of a few hundred records does not
require a policy organization with Task Forces, Regional Statements and
so forth. Responding to requests to change secondary nameservers does
not require a policy formulated by committee, it requires a simple
protocol. The only areas of ccTLD policy which might be thought to
impinge on the operator performing these IANA functions are those
concerning redelegations – the equivalent of changing maintainer objects
in the database. Any such decisions to redelegate should be made by the
national government concerned in consultation with the internet
community of that country, and the existing and proposed ccTLD operator,
and neither by ICANN, IANA, nor by vote of other ccTLD operators.
Provided the appropriate national government makes an authenticated
request to the IANA operator, and that request is not successfully
appealed by the existing manager (as to the consultation), the operator
should act on it. Appeals should be heard by a panel of  independent
experts external both to the IANA operator and the country involved.
Questions as to the identity of the national government  connected with
a ccTLD, for instance after revolution or civil war, should be left to
the ISO 3166 Maintenance Agency (to determine the mapping between the
ccTLD and a UN recognized country only), and the appropriate UN body (to
determine the recognized national government of that country). These
functions should not be duplicated by the IANA operator. Nominet
believes that ICANN has made a fundamental error in overplaying its role
in respect of the ccTLDs beyond that of the current IANA operator,
perhaps due to a mistaken belief as to the applicability to the ccTLDs
of ICANN's wider role to date with respect to gTLDs in policy making,
and regulation (such as registrar  accreditation); this appears to be
borne out by the fact that whilst the ccTLD operators have been asked to
contribute a third of ICANN's budget, much of the expenditure is devoted
to gTLD issues and dealing with internal US politics entirely
unconnected with any matters pertinent to ccTLDs. Any reform should
concentrate on reducing bureaucracy and costs within ICANN, and
increasing its operational effectiveness, rather than the converse,
which would be the effect of this proposal. An IANA function such as
Nominet describes would, however, be comparatively cheap to run.

3. The remit of the ccNSO should specifically exclude operational
matters. These should be the purview of operational contracts between
ccTLD manager and the IANA operator describing that operator's
obligations to perform the IANA functions as described above, and
equally technical requirements on the ccTLD manager. Nominet recognizes
the vital role of IANA, and thus underlines the need for any such
contracts to have service levels detailed within them. Nominet notes
with disappointment that ICANN has so far been unwilling to enter into
any form of contract describing the operational functions it purports to
perform as IANA, despite several initiatives by the ccTLD community (for
example from CENTR).

4. Nominet does not accept the "Region Structuring" proposed. Firstly,
such structuring would only make sense if it were perceived that there
was greater homogeneity of views amongst regions than between regions.
Secondly, this causes duplication and confusion with other regional
bodies such as CENTR.

5. Nominet UK does not accept the implied "one ccTLD one vote"
structure, which contrasts notably with ICANN's views on financial
contributions. However, instead of proposing alternative complicated
structures of no doubt equally dubious electoral and democratic
validity, Nominet proposes that ICANN should concentrate on development
of policy by consensus. Decisions made through the proposed voting
process, and no doubt any other, will always be subject to accusations
of invalidity. Nominet reminds ICANN that its function in this respect
is to operate a database. Far more complex issues within the industry
have been successfully determined in this manner, for instance the
proceedings of RIPE (operating a rather larger database), and the IETF.
Nominet notes that confrontational acts by ICANN, such as its threats to
withhold provision of essential services such as management of changes
to addresses, name servers etc in an attempt to enforce the party
concerned into a contractual relationship which is unacceptable to
almost all ccTLDs, have done little to contribute to an atmosphere where
policy can be made by consensus.

6. The section on Board Voting (clause 13b) exemplifies much that is
wrong with this proposal. Either the decisions of the ccNSO should be
binding on ICANN, or they should not be. This clause in essence says the
decisions will be binding unless ICANN's board thinks that they ought
not to be binding, rather making the entire already heavyweight process
a charade. Stripping away the otiose wording, this voting process is the
exact logical equivalent of: "The Board shall adopt the policy according
to the Council if and only if Board believe such a policy is in the best
interests of the ICANN community and ICANN". As this is the actual
substance, it would be more honestly phrased if the document stated it
in this manner, as opposed to maintaining the  pretence that the policy
is binding on ICANN.

In summary, Nominet restates the IANA function is a vital, but relative
simple function almost entirely concerned with the management of a small
database. Policy issues are relatively small (compared to those with the
gTLDs), and should be developed by consensus. Nominet retains its
position of supporting the need for a lightweight overarching body
performing these IANA functions at an economical rate. It should also
work on best practices for country code operators on a consensual
basis, in parallel with, and in consultation with, organisations such as
CENTR. Nominet notes with disappointment that it appears increasingly
likely that this may only be possible outside of the current ICANN
structure.

[Date Prev]   [Date Next]   [Thread Prev]   [Thread Next]   [Date Index]   [Thread Index]

Privacy Policy | Terms of Service | Cookies Policy