[CRISP-TEAM] Working on editing: reordering answers to match orders of questions
Izumi Okutani
izumi at nic.ad.jp
Mon Dec 22 13:04:27 CET 2014
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-en
“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)
More information about the CRISP
mailing list