[Iana-transition] FW: [NRO-IANAXFER] Editorial version of Internet Number Community IANA Stewardship, Proposal published
Sweeting, John
john.sweeting at twcable.com
Fri Jan 2 14:39:14 EST 2015
Good Afternoon ARIN community,
Please find information below on submitting feedback for the first draft
due 5 January 2014.
Thanks,
John
On 1/2/15, 1:17 PM, "Izumi Okutani" <izumi at nic.ad.jp> wrote:
>Dear Colleagues,
>
>
>
>This is a friendly reminder that the deadline for providing feedback to
>the first draft of the proposal from Internet Number Community on IANA
>Stewardship is: 5 January 2015.
>
>Based on the request made by a community member on this mailing list,
>please find below the text format of the first proposal. This is
>identical to the edited version of the first proposal published at:
>
>https://www.nro.net/wp-content/uploads/CRISP-IANA-PROPOSAL-Draft-24122014-
>clean.pdf
>
>We continue to welcome your feedback on <ianaxfer at nro.net> mailing list.
>
>
>
>Best Regards,
>
>Izumi Okutani
>Chair, Consolidated RIR IANA Stewardship Proposal (CRISP) team
>
>--------------------------------------------------------------------------
>-----
>Draft Response to the Internet Coordination Group Request for
>Proposals on IANA from the RIR community
>1. Proposal type
>
>Identify which category of the IANA functions this submission proposes
>to address:
>
>[ ] Names
>[ 口] Numbers
>[ ] Protocol Parameters
>
>
>
>I. Description of Community’s Use of IANA
>
>This section should list the specific, distinct IANA services or
>activities your community relies
>on. For each IANA service or activity on which your community relies,
>please provide the following:
>
>· A description of the service or activity.
>· A description of the customer(s) of the service or activity.
>· What registries are involved in providing the service or
> activity.
>· A description of any overlaps or interdependencies between
> your IANA requirements and the
> functions required by other customer communities
>
>-------
>· A description of the service or activity.
>
>The relevant IANA activities to the number resource communities are the
>allocation of IPv4 addresses, IPv6 addresses, and Autonomous System
>Numbers (“ASNs”) to the Regional Internet Registries (“RIRs”) as well as
>the delegation of the “IN-ADDR.ARPA” and “IP6.ARPA” DNS trees in
>accordance with the allocation of IPv4 and IPv6 addresses.
>
>· A description of the customer(s) of the service or activity.
>
>The RIRs manage the registration and distribution of Internet number
>resources (IPv4 and IPv6 addresses and ASNs) to members within their
>service regions. The five RIRs in operation at this point in time are:
>
>AFRINIC Serving Africa Founded in 2005
>APNIC Serving the Asia Pacific region Founded in 1993
>ARIN Serving North America Founded in 1997
>LACNIC Serving South America and the Caribbean Founded in 2001
>RIPE NCC Serving Europe, Central Asia and the Middle East Founded in 1992
>
>The five RIRs manage the distribution and registration of Internet
>number resources at the regional level, having received blocks of unused
>resources from the global pools managed by the IANA operator. The RIRs
>also facilitate the policy development processes of their
>respective communities.
>
>The five RIRs have a long-standing and straightforward operational
>relationship with IANA. IANA maintains the global pools of Internet
>number resources from which the RIRs receive allocations to distribute
>to their communities. The RIRs also coordinate with IANA to correctly
>register any resources that are returned to the global pools.
>Collectively, the system for administering Internet number resources is
>referred to as the "Internet Number Registry System" and is described
>in detail in RFC 7020.
>
>-------
>· What registries are involved in providing the service or
> activity.
>
>The most relevant IANA registries are the IPv4 address registry, the
>IPv6 address registry, and the ASN registry. Delegation of
>“IN-ADDR.ARPA” and “IP6.ARPA”domain names also requires interaction with
>the .ARPA zone registry.
>
>-------
>· A description of any overlaps or interdependencies between
> your IANA requirements and the
> functions required by other customer communities.
>
>The Internet Engineering Task Force (“IETF”) is responsible for policy
>relating to the entire IP address space and AS number space. Through
>the IANA protocol parameters registries, the IETF delegates unicast IP
>address ("IANA IPv4 Address Space Registry" and "IPv6 Global Unicast
>Allocations Registry") and AS number space (“ASN Registry) to the RIR
>system [RFC7020]. Note that within each IANA registry, there are also
>reserved values or ranges, and special-purpose registries, which are
>outside the Internet Numbers Registry System and instead administered
>under the direction of the IETF. The delineation of the specific ranges
>delegated to the Internet Number Registry system is provided in RFC
>7249. It is expected that the boundary between IETF-managed and Internet
>Number Registry-managed parts of the number spaces may change from time
>to time, with agreement between the IETF and the RIRs. Potential
>reasons for changes include the possibility
>that the IETF may release some previously reserved space for general
>use, or may reserve some previously unused space for a special purpose.
>The global Internet community also depends upon the IANA operator for
>administration of the special-purpose “IN-ADDR.ARPA” and “IP6.ARPA” DNS
>zones which are associated with IPv4 and IPv6 number resources
>respectively. These zones are delegated to IANA by the Internet
>Architecture Board (“IAB”) and “[s]ub-delegations within this hierarchy
>are undertaken in accordance with the IANA’s address allocation
>practices” (RFC3172). The IANA operator administers these zones as
>“agreed technical work items” per the IETF- Internet Corporation for
>Assigned Names and Numbers (“ICANN”) IANA MoU. It is important to note
>that this work is outside the scope of the National
>Telecommunications and Information Administration (“NTIA”) contract.
>
>Relevant links:
>IETF-ICANN MoU Concerning the Technical Work of the Internet Assigned
>Numbers Authority:
>https://www.icann.org/resources/unthemed-pages/ietf-icann-mou-2000-03-01-e
>n
>“The Internet Numbers Registry System”, RFC 7020:
>https://tools.ietf.org/html/rfc7020 “Internet
>Numbers Registries”, RFC 7249: https://tools.ietf.org/html/rfc7249
>
>
>
>II. Existing, Pre-Transition Arrangements
>
>This section should describe how existing IANA-related arrangements
>work, prior to the transition.
>
>A. Policy Sources
>
>This section should identify the specific source(s) of policy which must
>be followed by the IANA functions operator in its conduct of the
>services or activities described above. If there are distinct sources
>of policy or policy development for different IANA activities, then
>please describe these separately. For each source of policy or policy
>development, please provide the following:
>
>· Which IANA service or activity (identified in Section I) is
> affected.
>· A description of how policy is developed and established and
> who is involved in policy development and establishment.
>· A description of how disputes about policy are resolved.
>· References to documentation of policy development and dispute
> resolution processes.
>
>-------
>· Which IANA service or activity (identified in Section I) is
> affected.
>
>The Internet number resource registries.
>
>It is important to note that allocations of Internet number resources
>from IANA to the RIRs and its registrations in IANA registries, as well
>as delegations of “IN-ADDR.ARPA” and “IP6.ARPA” domains, described in
>Section I, are conducted between IANA and the RIRs without involvement
>by the NTIA.
>
>-------
>· A description of how policy is developed and established and
> who is involved in policy development and establishment.
>
>The policies under which the IANA operator manages the global pools of
>Internet number resources (excluding those address ranges reserved by
>the IETF for specific technical purposes) are developed and agreed by
>the five RIR communities via open, transparent and bottom-up policy
>development processes. Each RIR community engages in its own regional
>policy development process; these processes are open to all stakeholders
>regardless of specific background or interest. Links to each of the five
>regional Policy Development Processes (“PDPs”) are included under in the
>RIR Governance Matrix published on the Number Resource Organization
>(“NRO”) website [www.nro.net/about-the-nro/rir-governance- matrix].
>
>Any individual may submit a global proposal. Each RIR community must
>ratify an identical version of the proposed policy. The NRO Executive
>Council (“NRO EC”) then refers the coordinated proposal to the Address
>Supporting Organization (“ASO”) Address Council (“ASO AC”), which
>reviews the process by which the proposal was developed and, under the
>terms of the ASO Memorandum of Understanding (“ASO MoU”), passes it to
>the ICANN Board of Directors for ratification as a global policy.
>
>There are currently three global policies relating to management of the
>global pools of IPv4 addresses, IPv6 addresses and AS Numbers
>[https://www.nro.net/policies]:
>
>(a) IANA Policy for Allocation of IPv6 Blocks to Regional Internet
>Registries;
>(b) IANA Policy for Allocation of ASN Blocks to Regional Internet
>Registries; and
>(c) Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the
>IANA.
>
>There is a fourth global policy agreed by the RIR communities, ICP-2,
>"Criteria for Establishment of New Regional Internet Registries".
>
>The global Policy Development Process (“gPDP”) described in “Global
>Policy Development Process Document”
>[https://www.nro.net/documents/global-policy-development- process] is
>used for all of the number-related IANA activities described in Section
>I, but the policy that
>“IN-ADDR.ARPA” and “IP6.ARPA” domains must be delegated following IPv4
>and IPv6 address allocations is specified by the IETF (most recently in
>RFC 3172).
>
>-------
>· A description of how disputes about policy are resolved.
>
>The gPDP is formally described in "Attachment A" of the ASO MoU, signed
>by ICANN and the RIRs in 2004 (and signed by AFRINIC when it was
>established as the fifth RIR in 2005). This MoU includes provisions for
>resolving disputes between ICANN and the RIRs or their communities. It
>is important to note that while the gPDP allows for the ICANN Board to
>dispute the outcome of a consensus community decision (escalating to
>mediation between ICANN and the RIRs), it does not include any role for
>the IANA contract holder (currently the NTIA). The ASO MoU is an
>agreement between the RIR communities and ICANN; NTIA has no oversight
>role in policy-making as regards management of the global Internet
>number resource pools, and its transition out of its current role would
>have minimal effect on the policy-making framework.
>
>A separate MoU, the NRO MoU, establishes the NRO as "a coordinating
>mechanism of the RIRs to act collectively on matters relating to the
>interests of the RIRs", and includes provisions for dispute resolutions
>between RIRs on issues relating to global policy development or
>implementation.
>
>It is the responsibility of the NRO Number Council (“NRO NC”), a group
>comprising three community members selected by each of the five RIR
>communities, to confirm that the documented RIR PDPs have been followed
>in the development and approval of a new policy or policy change.
>Further, this group reviews the policy followed by each of the RIR
>communities to assure itself that the significant viewpoints of
>interested parties were adequately considered,and only after this
>confirmation does it then consider forwarding global policy proposals to
>the ICANN Board for ratification.
>
>The NRO NC also acts in the role of the ICANN ASO AC, and as such,
>presents the agreed global policy proposal to the ICANN Board for
>ratification and operational implementation.
>
>The ICANN Board reviews the received global number resource policy
>proposals and may ask questions and otherwise consult with the ASO
>Address Council and/or the individual RIRs acting collectively
>through the NRO. The ICANN Board may also consult with other parties as
>the Board considers appropriate. If the ICANN Board rejects the proposed
>policy, it delivers to the ASO ACa statement of its concerns with the
>proposed policy, including in particular an explanation of the
>significant viewpoints that were not adequately considered during the
>regular RIR processes. By agreement of all RIRs, the ASO AC may forward
>a new proposed policy (either reaffirming the previous proposal or
>a modified proposal) to the ICANN Board. If the resubmitted proposed
>policy is rejected for a second time by ICANN, then the RIRs or ICANN
>shall refer the matter to mediation.
>
>In case of disputes where mediation has failed to resolve the dispute,
>the ICANN ASO MoU agreement provides for arbitration via ICC rules in
>the jurisdiction of Bermuda or such other location as is agreed between
>the RIRs and ICANN. It is also worth noting that the RIRs have been
>participating (as the ASO) in the periodic independent review processes
>for Accountability and Transparency (ATRT) that is called for per
>ICANN’s Bylaws.
>
>-------
>· References to documentation of policy development and dispute
> resolution processes.
>
>Relevant links:
>ICANN ASO MoU:
>https://www.nro.net/documents/icann-address-supporting-organization-aso-
>mou
>NRO MoU: https://www.nro.net/documents/nro-memorandum-of-understanding
>About the NRO Number Council:
>https://www.nro.net/about-the-nro/the-nro-number-council RIR
>Governance Matrix:
>https://www.nro.net/about-the-nro/rir-governance-matrix
>Global Policies: https://www.nro.net/policies
>
>
>
>B. Oversight and Accountability
>
>This section should describe all the ways in which oversight is
>conducted over IANA’s provision of the services and activities listed in
>Section I and all the ways in which IANA is currently held accountable
>for the provision of those services. For each oversight or
>accountability mechanism, please provide as many of the following as
>are applicable:
>
>· Which IANA service or activity (identified in Section I) is
> affected.
>· If the policy sources identified in Section II.A are affected,
> identify which ones are affected and explain in what way.
>· A description of the entity or entities that provide oversight
> or perform accountability functions, including how individuals
> are selected or removed from participation in those entities.
>· A description of the mechanism (e.g., contract, reporting
> scheme, auditing scheme, etc.).
> This should include a description of the consequences of the
> IANA functions operator not meeting the standards established
> by the mechanism, the extent to which the output of the
> mechanism is transparent and the terms under which the
> mechanism may change.
>· Jurisdiction(s) in which the mechanism applies and the legal
> basis on which the mechanism rests.
>
>-------
>· Which IANA service or activity (identified in Section I) is
> affected.
>
>The Internet number resource registries.
>
>-------
>· If the policy sources identified in Section II.A are affected,
> identify which ones are affected and explain in what way.
>
>A decision by the NTIA to discontinue its stewardship of the IANA
>functions, and therefore its contractual relationship with the IANA
>functions operator, would not have any significant impact on the
>continuity of Internet number-related IANA services currently provided
>by ICANN. However, it would remove a significant element of oversight
>from the current system.
>
>There is no contractual obligation directly to the Internet number
>resource community for the IANA operator to provide IANA registry
>services for the Internet number registries; IANA services for
>the Internet number registries are provided by ICANN since its formation
>as a result of the NTIA IANA Functions contract and hence IANA services
>for the Internet number registries are presently
>subject to change per that agreement.
>
>-------
>· A description of the entity or entities that provide oversight
> or perform accountability functions, including how individuals
> are selected or removed from participation in those entities.
>
>All institutional actors with a role in management of Internet number
>resources are accountable to the open communities that make and agree on
>the policies under which those resources are distributed and registered.
>The mechanisms used to ensure and enforce this accountability differ for
>each of these actors.
>
>1. NTIA
>ICANN, as the current operator of the IANA functions, is obligated by
>the NTIA agreement to carry out management of the global IP address and
>AS Number pools according to policies developed by the communities.
>
>While the IANA operator escalation and reporting mechanisms are public
>in nature, the Internet number community is primarily represented in
>oversight of the IANA operator performance by the RIRs, which are
>member-based based organizations with elected governance boards.
>Currently, the NTIA does not have an oversight role in this regard.
>
>The ultimate consequence of failing to meet the performance standards or
>reporting requirements is understood to be a decision by the contracting
>party (the NTIA) to terminate or not renew the IANA
>functions agreement with the current contractor (ICANN).
>
>2. The Regional Internet Registries
>
>Administration by the IANA operator consists predominantly of
>processing of requests from the RIRs for issuance of additional number
>resources. The five RIRs are intimately familiar with global number
>resource policies under which the requests are made and maintain
>communications with the IANA operations team throughout the request
>process.
>
>The RIRs are not-for-profit membership associations, and as such are
>accountable to their members by law. The specific governance processes
>for each RIR differ depending on where they have been established and
>the decisions made by their membership, but in all RIRs, members have
>the right to vote individuals onto the governing Board and to vote on
>specific funding or operational resolutions.
>
>At the same time, an RIR's registration and allocation practices are
>directed by policies developed by its community. Each RIR community's
>PDP defines how these policies are developed, agreed and accepted for
>operational implementation.
>
>The corporate governance documents and PDPs of each RIR and its
>community are accessible via the RIR Governance Matrix, published on the
>NRO website.
>
>-------
>· A description of the mechanism (e.g., contract, reporting
> scheme, auditing scheme, etc.).
>This should include a description of the consequences of the IANA
>functions operator not meeting the standards established by the
>mechanism, the extent to which the output of the mechanism is
>transparent and the terms under which the mechanism may change.
>
>The NTIA IANA Agreement currently defines obligations of the IANA
>operator for Internet number resources.
>
>This obligation is specifically noted in section C.2.9.3 of the NTIA
>agreement:
>
>C.2.9.3 Allocate Internet Numbering Resources --The Contractor shall
>have responsibility for allocated and unallocated IPv4 and IPv6 address
>space and Autonomous System Number (ASN) space based on established
>guidelines and policies as developed by interested and affected parties
>as enumerated in Section C.1.3.
>
>The NTIA agreement also lays out specific deliverables for the IANA
>operator (ICANN) to produce as a condition of the agreement (see
>"Section F – Deliveries and Performance"), including performance
>standards developed in cooperation with the affected parties (in the
>case of the Internet number resource pools, the affected parties include
>the RIRs and their communities), customer complaint
>procedures and regular performance reporting.
>
>These deliverables are met by ICANN via monthly reporting on their
>performance in processing requests for the allocation of Internet number
>resources; these reports include IANA operator performance against key
>metrics of accuracy, timeliness, and transparency, as well as the
>performance metrics for individual requests. The IANA operations team
>also provides escalation procedures for use in resolving any issues with
>requests, as per the "IANA Customer Service Complaint Resolution Process".
>
>-------
>· Jurisdiction(s) in which the mechanism applies and the legal
> basis on which the mechanism rests.
>
>Jurisdiction for this current mechanism is the United States of America
>under applicable Federal government contracting laws and regulations.
>
>Relevant links:
>NTIA IANA Agreement:
>http://www.ntia.doc.gov/page/iana-functions-purchase-order
>ICANN ASO MoU:
>https://www.nro.net/documents/icann-address-supporting-organization-aso-
>mou
>NRO MoU: https://www.nro.net/documents/nro-memorandum-of-understanding
>IANA Customer Service Complaint Resolution Process:
>http://www.iana.org/help/escalation- procedure
>IANA Performance Standards Metrics Report:
>http://www.iana.org/performance/metrics
>RIR Governance Matrix:
>https://www.nro.net/about-the-nro/rir-governance-matrix
>
>
>
>III. Proposed Post-Transition Oversight and Accountability
>Arrangements
>
>This section should describe what changes your community is proposing to
>the arrangements listed in Section II.B in light of the transition. If
>your community is proposing to replace one or more existing arrangements
>with new arrangements, that replacement should be explained and all of
>the elements listed in Section II.B should be described for the new
>arrangements. Your community should
>provide its rationale and justification for the new arrangements.
>
>If your community’s proposal carries any implications for the interface
>between the IANA functions and existing policy arrangements described in
>Section II.A, those implications should be described
>here.
>
>If your community is not proposing changes to arrangements listed in
>Section II.B, the rationale and justification for that choice should be
>provided here.
>
>-------
>The elements of this proposal are as follows:
>
>(1) ICANN to continue as the IANA functions operator on number
> resources;
>(2) Service level agreement with the IANA functions operator on
> number resources; and
>(3) Establishment of a Review Committee, with representatives
> from each RIR, to advise the NRO EC on the review of the
> IANA functions operator’s performance and meeting of
> identified service levels.
>
>To maintain stability and continuity in operations of the Internet
>number-related IANA services, very minimal changes to the arrangements
>listed in Section II.B are proposed, including the identification of the
>proposed initial IANA functions operator. As noted in numerous NRO
>communications over the past decade, the RIRs have been very satisfied
>with the performance of ICANN in the role of IANA functions operator.
>Taking this into account, and considering the strong desires expressed
>in the five RIR communities' IANA stewardship discussions for stability
>and a minimum of operational change, the Internet numbering community
>believes that ICANN should remain in the role of IANA functions operator
>for at least the initial term of the new contract.
>
>A decision by the NTIA to discontinue its stewardship of the IANA
>functions, and therefore its contractual relationship with the IANA
>functions operator, would not have any significant impact on
>the continuity of Internet number-related IANA services currently
>provided by ICANN. However, it would remove a significant element of
>oversight from the current system.
>
>The following is a proposal to replace the current NTIA IANA agreement
>with a new contract that more directly reflects and enforces the IANA
>functions operator's accountability to the open,
>bottom-up numbers community. Other than the replacement of the NTIA
>with the five RIRs as the party(ies) with whom the IANA functions
>operator would contract for provision of Internet number-related IANA
>services, the overall arrangements in Section II.B would remain with no
>change.
>
>The proposed arrangement involves the same IANA service or activity,
>policy sources identified in Section II.A are unaffected, the entities
>that provide oversight or perform accountability functions (the RIRs)
>remain the same, the consequence for failure to meet performance
>standards remains termination or decision not to renew the IANA
>functions agreement with the then-current contractor, and jurisdiction
>will be dependent on the chosen IANA functions operator.
>
>The Internet numbering community proposes that a new contract be
>established between the IANA functions operator and the five RIRs. The
>contract, essentially an IANA Service Level Agreement, would obligate
>the IANA functions operator to carry out those IANA functions relating
>to the global Internet number pools according to policies developed by
>the regional communities via the gPDP as well as management of the
>delegations within IN-ADDR.ARPA and IP6.ARPA domains. The agreement
>would include specific requirements for performance and reporting
>commensurate with current mechanisms, and would specify consequences
>should the contractor fail to meet those requirements, the means for the
>resolution of disputes between the parties, and the terms for renewal or
>termination of the contract. IANA operations should be
>reliable and consistent, with any registry changes made in an open and
>transparent manner to the global community. The agreement should also
>require the IANA operator to appropriately coordinate with any other
>operator of IANA-related registry services.
>
>To ensure the service level defined in the proposed contract is
>maintained and provided by the IANA functions operator, the NRO EC will
>conduct periodic reviews of the service level of the IANA number
>resource functions that serves each RIR and their respective
>communities. The NRO EC shall establish a Review Committee that will
>advise and assist the NRO EC in its periodic review. Any such Review
>Committee should be a team composed of representatives from each RIR
>region that will, as needed, undertake a review of the level of service
>received from the IANA functions operator and report to the NRO EC any
>concerns regarding any observed failure by the IANA functions operator
>to meet its contractual obligations under the proposed contract. Any
>such Review Committee will advise the NRO EC in its capacity solely to
>oversee the performance of the IANA number resource functions and the
>Review Committee’s advice and comment will be limited to the processes
>followed in the IANA functions operator’s performance under the proposed
>contract.
>
>If your community’s proposal carries any implications for the interface
>between the IANA functions and existing policy arrangements described in
>Section II.A, those implications should be described
>here.
>
>This proposal carries no implication for the interface between IANA
>functions and existing policy arrangements described in Section II.A.
>The text in "Attachment A" of the ICANN ASO MoU meets the current and
>anticipated requirements for a community-driven global policy
>development process.
>
>As an additional measure of security and stability, the RIRs have
>documented their individual accountability and governance mechanisms,
>and asked the community-based Number Resource Organization Number
>Council (NRO NC) to undertake a review of these mechanisms and make
>recommendations for improvements that may be warranted given the nature
>of the stewardship transition for Internet number resources.
>
>
>IV. Transition Implications
>
>This section should describe what your community views as the
>implications of the changes it proposed in Section III. These
>implications may include some or all of the following, or other
>implications specific to your community:
>
>· Description of operational requirements to achieve continuity
> of service and possible new service integration throughout the
> transition.
>· Risks to operational continuity and how they will be addressed.
>· Description of any legal framework requirements in the absence
> of the NTIA contract.
>· Description of how you have tested or evaluated the
> workability of any new technical or
> operational methods proposed in this document and how they
> compare to established arrangements.
>
>-------
>· Description of operational requirements to achieve continuity
> of service and possible new service integration throughout the
> transition.
>· Risks to operational continuity and how they will be addressed.
>
>The intent of the proposal described above is to:
>
>1. Minimize risks to operational continuity of the management of the
>Internet number- related IANA functions, and;
>2. Retain the existing framework for making those policies that
>describe the management of the global Internet number resource pools, as
>this framework is already structured to ensure open, bottom-up
>development of such policies.
>
>Under current arrangements, the NTIA is responsible for extending or
>renewing the IANA functions agreement, and setting the terms of that
>contract. A new contract with the five RIRs and the IANA functions
>operator as signatories would shift the responsibility for renewing,
>setting terms or terminating the contract to the RIRs, who would
>coordinate their decisions via the NRO EC (made up of the RIR Directors
>and Chief Executives). Decisions made regarding the contract would be
>based on operational circumstances, past performance and input from
>open, regional communities.
>
>The shift from the existing contractual arrangement to another
>contractual arrangement (perhaps relying on a set of distinct contracts)
>covering the IANA functions operator’s ongoing management
>of all the IANA functions should result in no operational change for
>management of the global Internet number resource pools. This will help
>minimize any operational or continuity risks associated with stewardship
>transition.
>
>By building on the existing Internet registry system (which is open to
>participation from all interested parties) and its structures, the
>proposal reduces the risk associated with creating new organizations
>whose accountability is unproven.
>
>The necessary agreement proposed for IANA operation services for the
>Internet number registries can be established well before the NTIA
>target date for transition (September 2015), as there are no changes to
>existing service levels or reporting that are being proposed, only a
>change in contracting party to align with the delegated policy authority.
>
>-------
>· Description of any legal framework requirements in the absence
> of the NTIA contract.
>
>The necessary legal framework in the absence of the NTIA contract will
>be fulfilled by the proposed agreement between the IANA functions
>operator and the five RIRs. As stated in Section III above,
>the contract, essentially an IANA Service Level Agreement, would
>obligate the IANA functions operator to carry out those IANA functions
>relating to the global Internet number pools according to policies
>developed by the regional communities via the gPDP as well as
>management of the delegations within IN-ADDR.ARPA and IP6.ARPA domains.
>The agreement would include specific requirements for performance and
>reporting commensurate with current mechanisms, and would specify
>consequences should the contractor fail to meet those requirements, the
>means for the resolution of disputes between the parties, and the terms
>for renewal or termination of the contract. IANA operations should be
>reliable and consistent, with any registry changes made in an open and
>transparent manner to the global community.
>
>The agreement should also require the IANA operator to appropriately
>coordinate with any other operator of IANA-related registry services.
>The contract would also provide for jurisdiction and governing law
>regarding the new arrangement.
>
>-------
>· Description of how you have tested or evaluated the
> workability of any new technical or
> operational methods proposed in this document and how they
> compare to established arrangements.
>· Risks to operational continuity and how they will be addressed.
>
>This proposal does not propose any new technical or operational methods.
> There is inclusion of a proposed Review Committee to be established by
>the five RIRs acting cooperatively and coordinating
>through the NRO EC; however, this does not carry any new operational
>method as the IANA functions operator would remain accountable to the
>party with whom it is contracting, in this case, the five RIRs in place
>of the NTIA. The proposed Review Committee is a tool for the five RIRs
>to evaluate and review performance of the IANA functions provided.
>
>
>
>V. NTIA Requirements
>
>Additionally, NTIA has established that the transition proposal must
>meet the following five requirements:
>
>· Support and enhance the multistakeholder model;
>· Maintain the security, stability, and resiliency of the
> Internet DNS;
>· Meet the needs and expectation of the global customers and
> partners of the IANA services;
>· Maintain the openness of the Internet.
>· The proposal must not replace the NTIA role with a
> government-led or an inter-governmental organization solution.
>
>This section should explain how your community’s proposal meets these
>requirements and how it responds to the global interest in the IANA
>functions.
>
>-------
>The proposal for the IANA stewardship transition for the Internet number
>registries builds upon the existing, successful framework used by the
>Internet number community today. The major characteristics of this
>approach include:
>
>1. Global number policy development which is open and transparent to
>any and all participants
>2. Continuance of existing IANA service levels, escalation processes,
>and reporting mechanisms
>3. Maintenance of independent review and ratification for developed
>global Internet number resource policy
>4. Continued use of periodic third-party independent reviews of
>accountability and transparency of processes
>5. No change of the existing IANA operator for maximum stability and
>security of operational processes and systems
>6. Accountable, member-based, globally-distributed RIR organizations
>providing routine IANA operational oversight for the Internet number
>registries
>7. No new organization is proposed. However, a new process within the
>RIR structures is proposed, where a Review Committee is established to
>advise and assist the NRO EC in its periodic review of the service level
>provided by the IANA functions operator.
>
>As a result of the approach taken (and its characteristics as outlined
>above), it is clear that the proposal from the Internet number community
>meets the stated NTIA requirements.
>
>
>VI. Community Process
>
>This section should describe the process your community used for
>developing this proposal, including:
>
>· The steps that were taken to develop the proposal and to
> determine consensus.
>· Links to announcements, agendas, mailing lists, consultations
> and meeting proceedings.
>· An assessment of the level of consensus behind your
> community’s proposal, including a description of areas of
> contention or disagreement.
>
>-------
>1. Regional and global process
>
>Each of the five RIR communities is discussing the IANA stewardship
>issues via mailing lists, at their RIR meetings and in other community
>forums. While these discussions have been uniformly open and
>transparent, with all discussions archived on mailing lists and meeting
>records, each community has adopted a specific process of their own
>choosing to reach an agreed community output.
>
>The results from the five regional processes fed a global process that
>produced this document. More details about the regional and global
>processes are given below, interspersed with links to relevant documents.
>
>2. AFRINIC regional process:
>The AFRINIC community held a consultative meeting on 25 May to 6 June
>2014 during the Africa Internet Summit (AIS'2014) in Djibouti in the
>"IANA oversight transition" workshop. As a follow up to the meeting,
>AFRINIC setup a mailing list to provide a platform for the African
>Internet community to discuss the IANA Oversight Transition process. The
>mailing list was announced on July 4, 2014 to develop a community
>position. The list and its archives can be found at:
>https://lists.afrinic.net/mailman/listinfo.cgi/ianaoversight
>
>A Dedicated web portal was setup for sharing information on the IANA
>stewardship transition with the AFRINIC community and is also available
>at http://afrinic.net/en/community/iana-oversight-transition
>
>AFRINIC also conducted a survey seeking community input on the IANA
>Stewardship Transition. The results of the survey are published
>at:
>http://afrinic.net/images/stories/Initiatives/%20survey%20on%20the%20iana%
>20stewardship
>%20transition.pdf
>
>
>The last face-to-face meeting at which IANA oversight transition
>consultations were held with the community was during the AFRINIC-21
>meeting in Mauritius, 22-28 November 2014. The recordings of
>the session are available at http://meeting.afrinic.net/afrinic-21/en/vod
>
>Discussions continued on the ianaoversight at afrinic.net mailing list,
>until the closure of the comments from the number resources communities
>set by the CRISP Team on 12th Jan 2015.
>
>3. APNIC regional process:
>APNIC, as the secretariat for the APNIC community has set up a public
>mailing list (announced on 1 Apr 2014) to develop a community position,
>and have discussions about the proposal from the region on IANA
>stewardship transition: http://mailman.apnic.net/mailman/listinfo/IANAxfer
>
>Webpage, dedicated to sharing up-to-date information on the IANA
>stewardship transition was set up, for the APNIC community members and
>wider community members who are interested in this issue can be updated:
>http://www.apnic.net/community/iana-transition
>
>Draft proposal was discussed at the dedicated session at the APNIC 38
>Meeting, which saw the general community consensus. The meeting provided
>remote participation tools to enable wider participation from
>communities across Asia Pacific and beyond, with live webcasts well as
>Adobe Connect virtual conference room.
>
>https://conference.apnic.net/38/program#iana
>
>The discussions continued on the "ianaxfer at apnic.net." mailing list,
>until the closure of the comments from the number resources communities
>set by CRISP Team as 12th Jan 2015.
>
>4. ARIN regional process:
>
><TBD>
>
>5. LACNIC regional process:
>
>
><TBD>
>
>6. RIPE regional process:
>The RIPE community agreed at the RIPE 68 Meeting in May 2014 that the
>development of a community position on IANA stewardship should take
>place in the RIPE Cooperation Working Group, and via that working
>group's public mailing list: https://www.ripe.net/ripe/mail/wg-
>lists/cooperation
>
>The RIPE NCC, as secretariat for the RIPE community, also facilitated
>discussions on the IANA stewardship in national and regional forums
>across the RIPE NCC service region. Summaries of these discussions were
>posted to the RIPE Cooperation Working Group mailing list and on the
>RIPE website:
>https://www.ripe.net/iana-discussions
>
>Between September and November 2014, RIPE community discussion centered
>around developing a set of principles reflecting the communities primary
>concerns in the development of an alternative IANA stewardship
>arrangement. These discussions are reflected in the discussions on the
>mailing list from that time:
>http://www.ripe.net/ripe/mail/archives/cooperation- wg/
>
>Discussions at the RIPE 69 Meeting in November 2014 saw general
>community consensus on the principles discussed on the mailing list, and
>support expressed for the three community members selected to join the
>Consolidated RIR IANA Stewardship Proposal (CRISP) team.
>
>RIPE Cooperation Working Group Session:
>https://ripe69.ripe.net/programme/meeting- plan/coop-wg/#session1
>RIPE 69 Closing Plenary Session:
>https://ripe69.ripe.net/archives/video/10112/
>
>-------
>7. Global process (CRISP Team)
>On 16 October 2014, the NRO EC proposed the formation of a Consolidated
>RIR IANA Stewardship
>
>Proposal (CRISP) team to develop a single Internet numbering community
>proposal to the IANA Stewardship Coordination Group (ICG). Each RIR
>community selected three members (two community members and one RIR
>staff) to participate in the team. The participants selected were:
>
>AFRINIC Region
>Alan P. Barrett – Independent Consultant
>Mwendwa Kivuva – Network Infrastructure Services, University of Nairobi
>Ernest Byaruhanga (Appointed RIR staff)
>
>ARIN Region
>Bill Woodcock – President and Research Director of Packet Clearing House
>John Sweeting – Sr. Director, Network Architecture & Engineering at Time
>Warner Cable
>Michael Abejuela (Appointed RIR staff)
>
>APNIC Region
>Dr Govind – CEO NIXI
>Izumi Okutani – Policy Liaison JPNIC
>Craig Ng (Appointed RIR staff)
>
>LACNIC Region
>Nico Scheper - Curacao IX
>Esteban Lescano - Cabase Argentina
>Andrés Piazza (Appointed RIR staff)
>
>RIPE NCC Region
>Nurani Nimpuno – Head of Outreach & Communications at Netnod
>Andrei Robachevsky – Technology Programme Manager at the Internet
>Society Paul Rendek (Appointed
>RIR staff)
>
>Steps and timeline for proposal development and links to announcements,
>mailing lists, and
>proceedings -
>https://www.nro.net/nro-and-internet-governance/iana-oversight/timeline-fo
>r-rirs-
>
>engagement-in-iana-stewardship-transition-process
>
>-------
>8. Assessment of consensus level
><TBD>
>
><END>
>
>On 2014/12/29 20:43, Izumi Okutani wrote:
>> Dear Colleagues,
>>
>>
>> CRISP Team has published an editorial version of the Internet
>> numbers community's response to the Request For Proposals issued by the
>> IANA Stewardship Coordination Group (ICG):
>>
>> http://www.nro.net/crisp-proposal-first-draft-1-1
>>
>> From the initial draft we published on 19th Dec [*], we have made
>> editorial changes only. No changes are made in contents of the proposal.
>>
>> [*]
>>
>>https://www.nro.net/wp-content/uploads/CRISP-IANA-PROPOSAL-First-Draft1.p
>>df
>>
>> The editorial changes are intended to clarify our answers to RFP, by
>> re-ordering answers in the same order as questions listed in each
>> Section. Some small additions have been made to address points that had
>> not been answered in the earlier draft. Finally, there are some changes
>> made for stylistic reasons.
>>
>> The deadline of the comments to be submitted to <ianaxfer at nro.net>
>> mailing list remains the same: Monday 5th Jan 2015.
>>
>> Please let us know if you have any questions about version 1.1 of our
>> draft proposal, and we continue to welcome feedback from the community.
>>
>>
>> Best Regards,
>> Consolidated RIR IANA Stewardship Proposal Team (CRISP Team)
>>
>
>
>_______________________________________________
>ianaxfer mailing list
>ianaxfer at nro.net
>https://www.nro.net/mailman/listinfo/ianaxfer
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
More information about the Iana-transition
mailing list