Relations with the ccTLDs (was Re: [ga] Re: Violations of the Bylaws?

["Peter Dengate Thrush" <barrister@chambers.gen.nz>]

Dear Vint
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
development process?

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 :
http://www.wwtld.org/meetings/cctld/Bucharest2002/ccTLD_response_ERC.html

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
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.

    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 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
cctld community.

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
supporting.

My regards

Peter Dengate Thrush
Senior Vice Chair
Asia Pacific TLD Association
ccTLD Adcom Meeting Chair
****************************************************************************
*********
Dear Vint,

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
http://www.wwtld.org/~wwtld/livescribe/KimDavies.html

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
discussions.""
(see http://www.iana.org/reports/bi-report-16jul02.htm)


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
      transfer."

See http://www.isi.edu/in-notes/rfc1591.txt


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
developed policies.

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
a contract.

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
http://www.icann.org/minutes/minutes-12feb02.htm

"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
policies?

For your guidance, I enclose a section from the reconsideration report in
relation to ICP-3, which can be seen at
http://www.icann.org/committees/reconsideration/rc01-5.htm

"The request for withdrawal has caused the committee to consider the
   circumstances under which documents should be designated within the ICP
series.
   Documents should be included in the ICP series, of course, only to
document
   existing policies (whether longstanding or newly established by Board
action within
   the ICANN policy-formulation framework). Designation of a document in the
ICP
   series should not itself create new policy; where new policies are being
   established or existing policies are being modified ICANN's various
procedures for
   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
http://www.wwtld.org/~wwtld/livescribe/cctldposition.html

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
agreement.

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
global."

Before signing contracts, the cctlds need to be assured that it is accepted
that
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
current
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
going
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,

My regards

Peter Dengate Thrush
cctld Adcom

****************************************************************************
*********
---- Original Message -----
From: "vinton g. cerf" <vinton.g.cerf@wcom.com>
To: <DannyYounger@cs.com>; <ga@dnso.org>
Cc: <icann-board@icann.org>
Sent: Sunday, August 25, 2002 9:11 AM
Subject: [ga] Re: Violations of the Bylaws?


> Danny,
>
> 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.
>
> Vint
>
> 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)
periodically
> >a calendar of scheduled meetings for the upcoming year, and (ii) in
advance
> >of each Board meeting, a notice of the fact and time that such meeting
will
> >be held and, to the extent known, an agenda for the meeting. If
reasonably
> >practicable, the Board shall post notices of special meetings of the
Board at
> >least fourteen (14) days prior to the meetings."  The notice of the
special
> >meeting of the Board was not posted 14 days in advance of such meeting --
Why?
> >
> >2.  Our bylaws state:  "If the Board declines to accept any
recommendation of
> >a Supporting Organization, it shall return the recommendation to the
> >Supporting Organization for further consideration, along with a statement
of
> >the reasons it declines to accept the recommendation.  If, after
reasonable
> >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
from
> >Supporting Organizations, and the Board finds there is a justification
for
> >prompt action, the Board may initiate, amend or modify and then approve a
> >specific policy recommendation."   With respect to WLS, the Board
declined to
> >accept the recommendation of the DNSO yet failed to return the
recommendation
> >to the DNSO for further consideration -- Why?
> >
> >I do not seek to challenge the Board's decision with regard to WLS, only
the
> >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
> WorldCom
> 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 ga@dnso.org list.
> Send mail to majordomo@dnso.org 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 ga-full@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-full" in the body of the message).
Archives at http://www.dnso.org/archives.html