Relations with the ccTLDs (was Re: [ga] Re: Violations of the Bylaws?
May I remind you that I am waiting for a substantive answer to my question
of 19 July, concerning the status of ICP-1, which appears not to have been
adopted as an ICANN policy, but adopted as a document number only? The
consequential question was, if it was intended that the Board would be
approving the policy, why was that not put through the proper policy
With apologies for the length, I paste it below for convenience.
Shorn of the rhetoric was the fundamental issue for the cctlds - there
appears to be no security that policy decisions affecting cctlds will be
put through the process mandated by the bylaws.
For this reason, the ccTLD response to the Blueprint in Bucharest records as
a prime point of departure the issue of the ICANN board's role in relation
to ccTLD policies.
That response can be seen at :
The most fundamental issue expressed there is in relation to the Board's
ability to make (as distinguished from its ability to adopt) policy in
relation to cctlds.
An extract of that statement follows:
" The board should not make policy in those areas for which a support
The function of the board is to receive and respond to policy that has
been developed by
those organisations specifically intended, designed, populated and
staffed for the express
purpose of developing policy.
It is not the board's job to make policy, but rather to ensure that
policy developed is timely,
useful, appropriate, and compliant with the processes of the respective
SO providing it.
The Board may initiate policy discussions in an SO, and might provide
encouragement at various times in the SO's development process but it
cannot be the
Board's role to make policy in the absence of SO agreement. "
You will appreciate how urgent an answer on this question is becoming. On
the one hand, we have seen the US Department of Commerce questioning ICANN
as to how it is reviewing its processes to ensure stakeholders are heard,
and just recently seen the Board adopt a policy in apparent contradiction to
the vote of that part of ICANN charged with developing policy in the area in
issue, namely the WLS vote.
Leaders in the cctld community have begun a dialogue with the Board's ERC,
but that cannot proceed on the basis that the Blueprint is to be implemented
in its current form, and without attention to the matters raised in the
cctld statement above.
I hope you appreciate how deeply unsatisfying is your response to Mr
Younger's question below about the apparent breach of the bylaws in relation
to the WLS. An invitation to commence litigation, (which is how many will
regard your suggestion he begin the reconsideration process), is, with the
greatest of respect, not the sort of answer that reassures the cctlds that
ICANN will respect its bylaws in relation to cctld matters. You need to
appreciate how much harder it makes building support for ICANN among the
I look forward to your response on these issues, to reassure the cctld
community that ICANN is committed to becoming the White Paper-inspired body
it has the potential to become, and an organisation they should be
Peter Dengate Thrush
Senior Vice Chair
Asia Pacific TLD Association
ccTLD Adcom Meeting Chair
You will recall my question at Bucharest about the status of ICP-1.
Here is some further material to allow you to prepare a more formal
response than the meeting permitted.
I have also set out why this is part of an issue critical to the success of
ICANN, namely participation by cctlds and contracts between them and ICANN.
First, here is an extract from a Centr paper, which conveniently sets out
the differing statements concerning IANA access to cctld zone files:
"RFC 1591 -- http://www.ietf.org/rfc/rfc1591.txt
There must be a primary and a secondary nameserver that have IP
connectivity to the Internet and can be easily checked for
operational status and database accuracy by the IR and the IANA.
ICP-1 -- http://www.icann.org/icp/icp-1.htm
Because of its responsibilities for the DNS, the IANA must be
granted access to all TLD zones on a continuing basis. There
must be a primary and a secondary nameserver that have IP
connectivity to the Internet and can be easily checked via
access to zones for operational status and database accuracy
by the IANA.
The requirement for zone file access was only recently introduced.
ICANN's operating procedure, ICP-1, was referred to in ICANN board
resolution 02.10 on 12 February, 2002. It is unclear what status this
affords the document and whether it has been explicitly approved as an
operational policy by the board. However, ICP-1 was never considered or
approved by the ccTLD community and thus has not gained widespread
support. Many ccTLDs only recognise RFC 1591 as the authoritative
document on ccTLD management."
The paper can be seen at
The assertion has frequently been made that ICP-1 is merely some form of
re-statement of RFC 1591, or that it reflects what the IANA staff were
actually doing by way of operational performance. In any event, no new
policy is said to be involved.
You will agree that that interpretation, in the light of the above
documents, seems untrue or inaccurate.
Next, I invite you to consider the use which has been made of the
requirement in ICP-1 to consult with Governments in the case of a
re-delegation request. See, for example, this extract from the recent
announcement recommending the re-delegation of dotbi:
"In considering delegation or redelegation of a ccTLD, the IANA seeks input
from persons significantly affected by the transfer, particularly those
within the nation or territory which the ccTLD has been established to
benefit. As noted in ICP-1, the parties affected include especially the
relevant government or public authority: "The desires of the government of a
country with regard to delegation of a ccTLD are taken very seriously. The
IANA will make them a major consideration in any TLD delegation/transfer
I invite you to review the text of RFC 1591 and to note that this text
appears nowhere in it. Nor is there any reference to consulting with
governments. The text from RFC 1591 in fact reads as follows:
"For any transfer of the designated manager trusteeship from one
organization to another, the higher-level domain manager (the IANA
in the case of top-level domains) must receive communications from
both the old organization and the new organization that assure the
IANA that the transfer in mutually agreed, and that the new
organization understands its responsibilities.
It is also very helpful for the IANA to receive communications
from other parties that may be concerned or affected by the
I do not debate the usefulness or acceptability of this development. My
concern, and that of the ccTLDs is in relation to who has authority for
developing policies that cctld managers will abide by. There is little or no
disagreement that ICANN has failed, so far, in terms of reaching formal
agreements with the ccTLds. The fundamental reason has been, in my view,
ICANN's failure to recognise the limitations on the Board's ability to
impose policies on the ccTLDs.
Whereas ICANN needs to be, and is becoming the Local Internet Community for
the g-TLds, it cannot become that for the cctlds.
We already have, in terms of the active ccTLDs, a local internet community
to whom we are responsible, which includes our national governments. We will
not, and cannot, sign contracts that bind us, as does even the most recent
MoU between ICANN and Burundi, to an open-ended obligation to abide by ICANN
Here is an extract from that MoU:
"5.1 Conformity with ICANN Policies. The specifications and policies set
forth in ICP-1 (located at http://www.icann.org/icp-1.htm) and in Attachment
D shall apply to the operation of the Delegated ccTLD beginning at the
commencement of the term of this MoU. During the term of this MoU, the
Manager will also comply with any policies established through the ICANN
policy-development process described in Section 5.2 that by their terms
apply to the Delegated ccTLD.
5.2 Procedure of Establishment. During the term of this MoU, new or revised
specifications and policies applicable to the Delegated ccTLD may be
established through the ICANN process according to procedures that comply
with ICANN's bylaws and articles of incorporation. The Manager hereby
reaffirms its support for the ICANN process as the appropriate framework for
consensus-based formulation of policies for the global coordination of the
DNS, and pledges to participate in and support that process during the term
of this MoU. "
Now, ICP-1 is not, as we have seen, a policy developed by the "ICANN process
according to procedures that comply with ICANN's bylaws..." yet it is
being applied as if it were an ICANN policy. The MoU obliges cctlds signing
this type of contract to be bound by policies which have been made in
apparent breach of the Bylaws.
It should be no surprise that so few countries will bind themselves to such
I return to the question -what is the status of the Board's resolution in
February, which approves the name of the policy, but carefully avoids
adopting the policy itself?
The text of the resolution can be seen at
"Resolved [02.10] that the Board adopts the designation of ICP-1, ICP-2,
and ICP-3 as members of the ICP series of documents."
Second question: if the board intended to adopt the policy, will the Board
subject this policy to the ICANN bylaw process for the adoption of new
For your guidance, I enclose a section from the reconsideration report in
relation to ICP-3, which can be seen at
"The request for withdrawal has caused the committee to consider the
circumstances under which documents should be designated within the ICP
Documents should be included in the ICP series, of course, only to
existing policies (whether longstanding or newly established by Board
the ICANN policy-formulation framework). Designation of a document in the
series should not itself create new policy; where new policies are being
established or existing policies are being modified ICANN's various
policy formulation must be followed. "
What protection is there that future unilateral decisions will be made
without following the policy process, and become contractually binding on
cctlds because the board has adopted them?
The solution for cctlds is contained in the ccTLD
statement to the Board on Reform, and which can be seen at
The statement deals with the issue of policy making in relation to the
cctlds as follows;
"5. The board should not make policy in those areas for which a support
organization exists. The function of the board is to receive and respond to
policy that has been developed by those organisations specifically intended,
designed, populated and staffed for the express purpose of developing
policy. It is not the board's job to make policy, but rather to ensure that
policy developed is timely, useful, appropriate, and compliant with the
processes of the respective SO providing it. For example, the ccTLDs have
determined that "consensus policy" means as follows: "A consensus
recommendation is one that is supported by the affirmative vote of two
thirds of members voting in each geographic region. If any region votes
against a proposed policy, or it achieves less a two thirds majority vote in
any region it will be deemed to have failed. " Therefore the Board could not
adopt any policy binding on ccTLDs that had not been through this process.
The Board may initiate policy discussions in an SO, and might provide
guidance and encouragement at various times in the SO's development process
but it cannot be the Board's role to make policy in the absence of SO
6. Policy for each ccTLD is primarily local and is therefore made locally by
the local internet community for the local internet community. The primary
purpose of the ccSO is to provide policy on the few matters which are of
global significance. Those have been recognized by the ccTLDs as : "... a
carefully definable set of global issues which can be put through the ccSO
consensus policy development process to the policy making process of the
Corporation. These are referred to herein as "global" policies." It will be
a part of the ccSO function to characterise issues as either local or
Before signing contracts, the cctlds need to be assured that it is accepted
this is the Board's role in relation to cctlds.
It will be the ccSO that determines whether a policy is applicable to
cctlds, and, when it has been through the ccSO, it will be for the Board to
ratify or remand it back to the SO. It cannot be advisory, and it cannot be
usurped by the "ICP-1 process".
Unless this is agreed, there is little prospect of cctlds endorsing the
reform proposal. A ccSO which does not have a policy making role is of
little value in safeguarding the interests of ccTLDs. If it is agreed, there
is a chance that cctlds will join
the ccSO, and will look to creating MoU's and other documents to confirm
their relationship with ICANN.
So, the fundamental question is -will policy be made the ICP-1 way, or is it
to be transparently made in a bottom-up way, by a self-organised,
industry-led and geodiverse ccSO?
I look forward to hearing from you,
Peter Dengate Thrush
---- Original Message -----
From: "vinton g. cerf" <firstname.lastname@example.org>
To: <DannyYounger@cs.com>; <email@example.com>
Sent: Sunday, August 25, 2002 9:11 AM
Subject: [ga] Re: Violations of the Bylaws?
> I believe the board is operating within the ICANN Bylaws. If you think
> otherwise, then you are free to submit a reconsideration request outlining
> the specifics that you believe constitute a deviation from them.
> At 12:08 PM 8/24/2002 -0400, DannyYounger@cs.com wrote:
> >Dear Vint,
> >Before I proceed to file a reconsideration request, I would appreciate an
> >answer to the following questions:
> >1. Our bylaws state: "The Board shall post on the Web Site (i)
> >a calendar of scheduled meetings for the upcoming year, and (ii) in
> >of each Board meeting, a notice of the fact and time that such meeting
> >be held and, to the extent known, an agenda for the meeting. If
> >practicable, the Board shall post notices of special meetings of the
> >least fourteen (14) days prior to the meetings." The notice of the
> >meeting of the Board was not posted 14 days in advance of such meeting --
> >2. Our bylaws state: "If the Board declines to accept any
> >a Supporting Organization, it shall return the recommendation to the
> >Supporting Organization for further consideration, along with a statement
> >the reasons it declines to accept the recommendation. If, after
> >efforts, the Board does not receive a recommendation from the Supporting
> >Organization that it finds meets the standards of Section 2(e) of this
> >Article VI or, after attempting to mediate any disputes or disagreements
> >between Supporting Organizations, receives conflicting recommendations
> >Supporting Organizations, and the Board finds there is a justification
> >prompt action, the Board may initiate, amend or modify and then approve a
> >specific policy recommendation." With respect to WLS, the Board
> >accept the recommendation of the DNSO yet failed to return the
> >to the DNSO for further consideration -- Why?
> >I do not seek to challenge the Board's decision with regard to WLS, only
> >Board's conduct with respect to the Bylaws. Can you offer a rational
> >justification for the Board's violation of these bylaws?
> Vint Cerf
> SVP Architecture & Technology
> 22001 Loudoun County Parkway, F2-4115
> Ashburn, VA 20147
> 703 886 1690 (v806 1690)
> 703 886 0047 fax
> This message was passed to you via the firstname.lastname@example.org list.
> Send mail to email@example.com to unsubscribe
> ("unsubscribe ga" in the body of the message).
> Archives at http://www.dnso.org/archives.html
This message was passed to you via the firstname.lastname@example.org list.
Send mail to email@example.com to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html