RE: [aso-policy] ICANN/USG contract for IANA function

["Andrew McLaughlin" <mclaughlin@pobox.com>]

Paul:

A few informal comments on your note below:

-- The USG-IANA contract doesn't make new policy (we can't do that in a
contract, after all -- that's the ASO's job).  The contract represents a
transfer of functions to get the University of Southern California and DARPA
out of the business of the IANA function, and to get it squarely into ICANN,
where it is subject to the policy processes of the ASO and Address Council.
In short, the USG-IANA contract articulates current IANA policy.
-- If the ASO / Address Council aren't satisfied with current policy, they
have the ability to initiate changes through a recommendation to the ICANN
Board, as set forth in the ASO MoU.  The USG-IANA contract makes clear that
the transferred functions are now subject to the ICANN policy processes,
embodied in the ASO MoU and presently within the scope of the Address
Council's work.
-- A contract to effect transfer of the IANA functions was authorized by the
ICANN Board over a year ago, long before the creation of the ASO, and has
been waiting around for various bureaucratic reasons until last month.  Your
point about better consultation with the RIRs is, of course, a good one, and
one that I take quite seriously.  I'm certain that we could have done a
better job of consulting on the process & substance of the USG-IANA
contract.  But the contract simply does not make any changes in existing
policy.
-- If you think the contract language gets existing policy wrong, I'd very
interested in hearing about specifics.



[ The ICANN Bylaws define ICANN's responsibility to "refer proposals for
[ substantive policy" to the ASO where the content relates to the ASO's area
[ of responsibility, while the ASO MoU clearly defines the ASO's
[ responsibility for address policy.  These documents are available at:
[ 
[ http://www.icann.org/general/bylaws.htm#VI
[ http://www.aso.icann.org/docs/aso-mou.html (section 4b)
[ 
 


This is correct -- the IANA contract doesn't make any changes in substantive policy.  It restates existing IANA policy with respect to address allocation and the other IANA functions subject to prior agreements between the US Government and the Unversty of Southern California.  Again, if the ASO / Address Council are not satisfied, they have the authority to develop improved policies.



[ The RIRs believe that the ICANN/USG Contract contains provisions based on
[ substantive policies related to IP address management which are not
[ currently accepted as consensus policies of either the Address Council or
[ the Internet community.  Specifically:
[ 
[ (1) The policy under which ICANN can make allocations of address space is
[ the subject of a specific proposal raised on the aso-policy 
[ mailing list on
[ 20 January 2000 (see
[ http://aso.icann.org/mailing-lists/aso-policy/0001/msg00004.html), and on
[ which the Address Council has not finished deliberating.
[ 




Whether or not the policies described in the USG-IANA contract are "currently accepted as consensus policies" (I happen to think they are), they are the current IANA policies (that is, our best understanding of the IANA policies that existed under Jon Postel's management of the IANA, developed over many years, and articulated through the RFCs, IANA documents, and actual IANA practices).  Now, the Address Council is deliberating changes to current policy, which (as I keep repeating, forgive me!) is restated in the IANA contract, and is subject to modification through the ASO process.  The USG-IANA contract effects a clear transfer of functions to ICANN, so that the ASO process (whatever its outcome) can be given effect by ICANN.



[ (2) The administration of the "cable network block" 24/8 is the 
[ subject of a
[ specific RIR proposal to IANA, which has not been answered.
[ 



As I think Mike Roberts has pointed out, this proposal falls squarely within the scope of the Address Council's work.  We await its recommendation on the RIRs' proposal.  The whole idea of the ASO is that ICANN shouldn't do changes to address allocatio
n policy without the recommendation of the Address Council.  If the
ICANN/IANA staff's views on the RIR proposal would be useful to the AC,
we'll certainly provide them.



[ (3) The term "globally specified applications" is not recognised by the
[ address community, and is clearly subject to very wide interpretation.
[ 
[ 
[ While specific policies contained within the new contract are under
[ reconsideration, and while important policy terms of the contract are
[ ambiguous, it is not reasonable for ICANN to assume that such policies are
[ recognised by consensus, nor to enter into significant contracts on the
[ basis of that assumption without consultation with the relevant Supporting
[ Organisation, the ASO.
[ 



Because the USG-IANA contract doesn't alter existing policy, it doesn't in any way interfere with the Address Council's consideration of the issues you cite.  In fact, by clearly transferring those functions to ICANN, it enables the work of the ASO to be given effect.



[ We therefore request formally that this contract be subject to 
[ review by the
[ Address Council prior to its expiry on 30 September 2000, and that no
[ further contract or extension to this contract be undertaken without all
[ policy-related terms being specifically approved by the AC.
[ 
[ 


The first part of this sentence is is already the case -- the Address Council is warmly invited to review any and all parts of the contract, and to recommend changes in existing policy where it thinks advisable.  It is my understanding that the Address Council is moving forward with energy to do exactly that.

In my view, the second part of your last sentence sets the default in the wrong place -- on the contrary, existing IANA policy should continue until the Address Council recommends otherwise, and the Board approves the change (pursuant to the ASO MoU and ICANN Bylaws).  To say that existing IANA policies expire on September 30 absent specific ratification by the AC strikes me as a Bad Idea(tm), and inconsistent with ICANN's obligations to preserve continuity in policy.  Rather, the AC should address areas in which existing policies should be altered or refined.  Those areas can be as large or small as the AC decides.  Mike's exchange with the Address Council suggests that the AC is undertaking a fairly broad review of existing IANA policies.

Based on recent informal conversations with a few AC members and RIR staff (needless to say, I'm quite happy to talk with any and all AC members, RIR staff, or others about this), there seem to be few significant differences of opinion on the substance of ICANN/IANA's role in address allocation.  In my view, the goal of the AC should be to capture in words a policy that (1) gives the RIRs and others assurance that ICANN/IANA won't allocate addresses outside policies developed through the ASO & ICANN Bylaws;  and (2) gives non-RIR communities assurance that future needs & proposals requiring address space will be fairly evaluated by the Address Council (i.e., that address policy is sufficiently flexible to adjust to future changes in the Internet).  (Of course, that's a highly inexact description of the parties needing assurance, but it captures the basic tension that needs to be resolved by the Address Council).  I think both of those considerations can be reconciled.

Speaking for the ICANN staff, we're absolutely committed to adhering to the policy process of the ASO MoU;  under that process, the Address Council has primary responsibility to develop changes in policy;  we will respect the outcome of that process.  So if there are areas of existing IANA policy that you are not satisfied with (other than the 3 you cite above), by all means put them before the Address Council.

I take the basic unhappiness of your note very seriously, and will recommit myself to communicate earlier and better with the AC and RIRs.  With the AC starting to address substantive policy issues, I hope that we're nearing the end of these kinds of growing pains.

Best,

--Andrew



*       on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy     *
*   To unsubscribe:  send "unsubscribe" to aso-policy-request@aso.icann.org  *