[CRISP-TEAM] Working on editing: reordering answers to match orders of questions
Michael Abejuela
mabejuela at arin.net
Mon Dec 22 13:57:34 CET 2014
Thank you Izumi and Alan,
Attached is my redline. Izumi, once I have your redline, I can
incorporate yours and Alan's into the master document after our discussion
on the call today.
Thanks,
-Michael
--
Michael R. Abejuela
Associate General Counsel
ARIN
3635 Concorde Parkway
Suite 200
Chantilly, VA 20151
(703) 227-9875 (p)
(703) 263-0111 (f)
mabejuela at arin.net
Confidentiality Notice: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized review, copy, use,
disclosure, or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.
On 12/22/14, 7:04 AM, "Izumi Okutani" <izumi at nic.ad.jp> wrote:
>Thank you Alan.
>
>This is my part - I'm working on the red line version as this is
>probably confusing with many swaps of paragraphs.
>
>
>Izumi
>
>---------------------------------------------------------------------
>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
>
>1. A description of the service or activity.
>(Insert the first sentence of the first paragraph of the answer to
> Section. II "A. Policy Sources". ** part is changed by Izumi Okutani )
>
>The relevant IANA activities *to the number resource communities* are
>the allocation of IPv4 addresses, IPv6 addresses, and ASNs to the RIR¹s
>as well as the delegation of ³IN-ADDR.ARPA² and ³IP6.ARPA² domains to
>match the allocation of IPv4 and IPv6 addresses.
>
> · A description of the customer(s) of the service or activity.
>(Original first and second paragraphs of Section I: No change in
>description)
>
>
>(Move from the last parapgraph of "Regtional Internet Registries" in
>Section II. "B. Oversight and Accountability": No changes in description)
>
>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 Regional Internet Registries (RIRs) manage the registration and
>distribution of Internet number resources (IPv4 and IPv6 addresses and
>Autonomous System Numbers) 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 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.
>
>(No Relevant text found. Below added by Izumi Okutani)
>
>As described above, RIRs are the Internet Registries which receive
>allocations of Internet resrouces from IANA.
>
> · A description of any overlaps or interdependencies between
> your IANA requirements and the functions required by other
> customer communities
>
>(Keep third and the last paragraphs of of Section I)
>
>The 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 (³Autonomous System (AS) Numbers 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.
>Possible 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- ICANN IANA MOU. It s
>important to note that this work is outside the scope of the 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.
>
>(No relevant description: Below is added by Izumi.)
>
>The IANA service relevant to the number resource community (identified
>in Section I) is IANA function and activities related to number
>resources registries.
>
>However, there is no IANA service or activity related to number
>resources registries is affected by NTIA's stewardship transition in its
>direct operational sense.
>
>Allocations of Internet number sources from IANA to 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 RIRs without involvement by NTIA.
>
>
>[Alternative: Make is consisent with IETF's response and say "The number
>resources registries."]
>
>
>· A description of how policy is developed and established and
> who is involved in policy development and establishment.
>
>(Move from the last paragraph of this section to here: no change in
>description)
>
>Based on the global policy development process, global policies are
>developed for IPv4 addresses, IPv6 addresses and ASN¹s, which IANA will
>follow respectively, when making distribution of these resources.
>Global 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;
>(c) Global Policy for Post Exhaustion IPv4 Allocation Mechanisms
>by the IANA
>
>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.
>
>A global policy relating to the operation of the IANA function must be
>discussed in all five
>regions, with consensus agreement on the same policy text in all five
>communities. Each regional
>community has a distinct Policy Development Process (PDP), and a global
>policy proposal must
>progress through each of these regional PDPs to reach consensus. Links
>to each of the five regional
>PDPs are included under in the RIR Governance Matrix published on the
>NRO website.
>
>(Move second to the last paragraph in SectionI here: no change in
>description)
>The five open regional RIR communities develop the global policies under
>which allocations from the IANA-managed pools are made. This is an open,
>transparent and bottom-up process facilitated by the RIRs. There are
>currently three global policies relating to management of the
>global pools of IPv4 addresses, IPv6 addresses and AS Numbers. There is
>a fourth global policy agreed by the RIR communities, ICP-2, "Criteria
>for Establishment of New Regional Internet Registries".
>
># Observation: Overlaps with the first paragraph except the first
>sentence.
>
>(Move the last sentence of the first paragraph in SectionI here: no
>change in description)
>
>The global policy development process described *below --> in "Global
>Policy Development Process" document* is used for all of the
>number-related IANA activities, 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).
>
>Global Policy Development Process:
>https://www.nro.net/documents/global-policy-development-process
>
>
>· A description of how disputes about policy are resolved.
>[No changes]
>
>The global Policy Development Process (gPDP) is formally described in
>"Attachment A" of the ICANN Address Supporting Organization Memorandum
>of Understanding (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, as the IANA functions operator; 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 Number Resource Organization MoU (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 Number Resource Organization (NRO)
>Number Council, a group comprising three community members selected by
>each of the five 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 Number Council also acts in the role of the ICANN Address
>Supporting Organization (ASO) Address Council, 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 Address Council a 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 Address Council 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 Regional Internet
>Registries 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.
>
>(No relevant response. Below is added by Izumi.)
>
>The number resources registries.
>
>· If the policy sources identified in Section II.A are affected,
> identify which ones are affected and explain in what way.
>
>(Move the first paragraph of Section III there: No changes in description)
>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 or the ongoing community processes for development of policies
>relating to those services. However, it would remove a significant
>element of oversight from the current system.
>
>(Move the second to the last paragraph of "ICANN" here: No change in
>description)
>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.
>
>(No Changes)
>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. ICANN-->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 Regional Internet
>Registries, which are member-based based organizations with elected
>governance boards. Currently, the NTIA does not have an oversight role
>in this regard.
>
>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.
>
>2. The Regional Internet Registries
>
>(Moved from "ICANN section":** part added by Izumi)
>
>Administration *by the IANA operator*consists predominantly of
>processing of requests from the Regional Internet Registries for
>issuance of additional number resources. The five Regional Internet
>Registries 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
>Policy Development Process defines how these policies are
>developed, agreed and accepted for operational implementation.
>
>The corporate governance documents and Policy Development Processes 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.
>
>(**part added by Izumi)
>
>* NTIA IANA
>Agreement(http://www.ntia.doc.gov/page/iana-functions-purchase-order)
>defines * obligations of the IANA operator on Internet number resources *
>
>(Moved parapraph: No changes in description)
>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".
>
>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).
>
>## No description on the terms under which the mechanism may change.##
>
>· Jurisdiction(s) in which the mechanism applies and the legal
> basis on which the mechanism rests.
>
>(Moved from ICANN Section: No changes in description)
>Jurisdiction for this current mechanism is in the United States of
>America under applicable Federal government contracting laws and
>regulations.
>
>
>
>(2014/12/22 20:57), Alan Barrett wrote:
>> On Fri, 19 Dec 2014, Izumi Okutani wrote:
>>> To start, I'd like to suggest we split 6 sections into threes and each
>>> person reviews 2 sections.
>>>
>>> This is a tentative suggestion on who covers which part - if there is a
>>> set of Sections you feel strongly about, we can swap.
>>>
>>> Sections I & II : Izumi
>>> Sections III and IV : Michael
>>> Sections V & VI : Alan
>>
>> I have reviewed sections V (NTIA Requirements) and VI (Community
>> Process), and made some changes. I attach two plain text files
>> containing the "before" and "after" versions of these two sections.
>>
>> --apb (Alan Barrett)
>
>
>_______________________________________________
>CRISP mailing list
>CRISP at nro.net
>https://www.nro.net/mailman/listinfo/crisp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CRISP IANA PROPOSAL Section III-IV redline.pdf
Type: application/pdf
Size: 105047 bytes
Desc: CRISP IANA PROPOSAL Section III-IV redline.pdf
URL: <https://www.nro.net/pipermail/crisp/attachments/20141222/7a4cd123/CRISPIANAPROPOSALSectionIII-IVredline.pdf>
More information about the CRISP
mailing list