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

["Paul Wilson" <pwilson@apnic.net>]

Andrew,

Thanks for your response.

You have referred to existing agreements or contracts governing the IANA
function, however these do not appear to be available anywhere for
comparison.  Therefore, could you please post copies of past agreements
which relate to address allocation, assignment or management functions of
IANA?

One serious issue we have raised in our objection is the term "globally
specified applications", which as we have said is not commonly used or
understood within this community, and could be interpreted to mean
practically anything.  Does this term appear in any existing contracts or
agreements, and if so, please could you be sure to post these.

Thanks,

______________________________________________________________________
Paul Wilson, Director-General, APNIC               <pwilson@apnic.net>
http://www.apnic.net                          ph/fx +61 7 3367 0490/82
----------------------------------------------------------------------
See you at APRICOT 2000!  28 Feb - 2 Mar  http://www.apricot2000.ne.kr
----------------------------------------------------------------------



> -----Original Message-----
> From: owner-aso-policy@aso.icann.org
> [mailto:owner-aso-policy@aso.icann.org]On Behalf Of Andrew McLaughlin
> Sent: Friday, 3 March 2000 12:43
> To: Paul Wilson
> Cc: Mike Roberts; Louis Touton; aso-policy@lists.aso.icann.org;
> k13@nikhef.nl; Ken Fockler; Pindar Wong; Axel Pawlik; Kim Hubbard; John
> Curran
> Subject: RE: [aso-policy] ICANN/USG contract for IANA function
>
>
> 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
*


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