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

["vinton g. cerf" <vinton.g.cerf@wcom.com>]

ICP-1 is simply a statement of long-standing practice and doesn't seem to 
represent new policy. ICP-1 makes explicit a way to implement the policy
outlined in RFC 1591 but doesn't appear to create new policy, as I understand it.

At 05:41 PM 8/26/2002 +1200, Peter Dengate Thrush wrote:

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

Special meetings of the board require at least 48 hours notice - 14 days is for postal notification and 48 hours is for email. Telephone meetings are considered special meetings of the board.

The DNSO offered several alternatives to the Board including acceptance of WLS, with some built-in requirements - the board adopted that approach. 


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

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