Difference between revisions of "Ianaplan - current draft"

This document contains the a response to a request for proposals from

the IANA Stewardship Transition Coordination Group regarding the

protocol parameters registries.  It is meant to be included in an

aggregate proposal that also includes contributions covering domain

names and numbering resources that will be submitted from their

respective operational communities.  The IETF community is invited to

comment and propose changes to this document.

provisions of BCP 78 and BCP 79.

 

Internet-Drafts are working documents of the Internet Engineering

Task Force (IETF).  Note that other groups may also distribute

working documents as Internet-Drafts.  The list of current Internet-

Drafts is at http://datatracker.ietf.org/drafts/current/.

 

== 1.  IETF Introduction ==

In March of 2014 the U.S.  National Telecommunications & Information

Administration (NTIA) announced its intent to transition oversight of

Internet Assigned Numbers Authority (IANA) functions.  In that

announcement, NTIA asked the Internet Corporation for Assigned Names

and Numbers (ICANN) to establish a process to deliver a proposal for

transition.  As part of that process, the IANA Stewardship Transition

Coordination Group (ICG) was formed.  The charter for the ICG can be

found in Appendix B.  They solicited proposals regarding the

respective functions that IANA performs, in order that they may put

forth a proposal to the NTIA.  The final request for proposal (RFP)

can be found in Appendix C.

 

While there are interactions between all of the IANA functions and

IETF standards, this document specifically addresses the protocol

parameters registries function.  Section 1 (this section) contains an

introduction that is sourced solely within the IETF.  Section 2

contains the questionnaire that was written by the ICG and a formal

response by the IETF.  Because much of this memo is taken from a

questionnaire we have quoted questions with ">>> " and we have

prefaced answers to questions being asked with "IETF Response:".

 

Note that there are small changes to the content of the questions

asked in order to match the RFC format.

 

As if to demonstrate the last point, the following text was included

in a footnote in the original propsoal.

 

 

In this RFP, "IANA" refers to the functions currently specified in

the agreement between NTIA and ICANN [http://www.ntia.doc.gov/page/

iana-functions-purchase-order] as well as any other functions

traditionally performed by the IANA functions operator.  SAC-067

[https://www.icann.org/en/system/files/files/sac-067-en.pdf] provides

one description of the many different meanings of the term "IANA" and

may be useful reading in addition to the documents constituting the

agreement itself.

 

== 2.  The Formal RFP Response ==

The entire Request for Comments, including introduction, can be found

in Appendix C.

>>>

>>> 0. Proposal Type

>>>

>>> Identify which category of the IANA functions this

>>> submission proposes to address:

</pre>

IETF Response:

 

[XXX] Protocol Parameters

This response states the existing practice of the IETF, and also

represents the views of the Internet Architecture Board and the IETF.

<pre>

>>> I. Description of Community's Use of IANA Functions

>>>

>>> 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.

</pre>

IETF Response:

 

Many IETF protocols make use of commonly defined protocol parameters.

 

These parameters are used by implementers, who are the IETF's primary

users of the IETF standards and other documents.  To ensure

consistent interpretation of these parameter values by independent

implementations, and to promote universal interoperability, these

IETF protocol specifications define and require globally available

registries containing the parameter values and a pointer to

documentation of the associated semantic intent.  The IETF uses the

IANA protocol parameters registries to store this information in a

public location.

>>>

>>> A description of the customer(s) of the service or activity.

</pre>

IETF Response:

 

The IANA protocol parameters registries operator maintains the

protocol parameters registries for the IETF in accordance with all

relevant IETF policies, in accordance with the Memorandum of

Understanding[RFC2860] and associated supplemental agreements that

include service level agreements (SLAs) established between the IETF

and ICANN[MOUSUP].

 

The IETF is a global voluntary standards organization whose goal is

to make the Internet work better [RFC3595].  IETF standards are

published in the RFC series.  The IETF is responsible for the key

standards that are used on the Internet today, including IP, TCP,

DNS, BGP, and HTTP, to name but a few.

 

The IETF operates in an open and transparent manner [RFC6852].  The

processes that govern the IETF are also published in the RFC series.

 

The Internet Standards Process is documented in [RFC2026].  That

document explains not only how standards are developed, but also how

disputes about decisions are resolved.  RFC 2026 has been amended a

number of times, and those amendments are indicated in [RFC-INDEX].

 

The standards process can be amended in the same manner that

standards are approved.  That is, someone proposes a change by

submitting a temporary document known as an Internet-Draft, the

community discusses it, and if rough consensus can be found the

change is approved by the Internet Engineering Steering Group (IESG),

who also have day-to-day responsibility for declaring IETF consensus

on technical decisions, including those that affect IANA.  Anyone may

propose a change during a Last Call, and anyone may participate in

the community discussion.

>>>

>>> What registries are involved in providing the service or

>>> activity.

</pre>

IETF Response:

 

 

The protocol parameters registries are the product of IETF work.

 

Administration of the protocol parameters registries is the service

that is provided to the IETF.

>>>

>>> A description of any overlaps or interdependencies between your

>>> IANA requirements and the functions required by other customer

>>> communities

</pre>

IETF Response:

 

In this context, the IETF considers "overlap" to be where there is in

some way shared responsibility for a single registry across multiple

organizations.  In this sense, there is no overlap between

organizations because responsibility for each registry is carefully

delineated.  There are, however, points of interaction between other

organizations, and a few cases where we may further define the scope

of a registry for technical purposes.  This is the case with both

names and numbers, as described in the paragraphs below.  In all

cases, the IETF engages directly with the appropriate organizations

to ensure that each organization's policies are followed.

 

It is important to note that the IETF includes anyone who wishes to

participate.  Staff and participants from ICANN or the Regional

Internet Registries (RIRs) regularly participate in IETF activities.

 

* The IETF has specified a number of special use registries with regard to domain names.  These registries require coordination with the Generic Names Support Organization (GNSO).  We already perform this coordination.[RFC6761] * The IETF specifies the DNS protocol.  From time to time there have been and will be updates to that protocol.  As we make changes we will broadly consult the operational community about the impact of those changes, as we have done in the past.  

* The IETF specifies minimum requirements for root servers. Should those requirements change, we will inform ICANN.  

* The routing architecture has evolved over time, and is expected to continue to do so.  Such evolution may have an impact on appropriate IP address allocation strategies.  As and when that happens, we will consult with the RIR community, as we have done in the past.  

 

* The IETF is responsible for policy relating to the entire IP address space and AS number space.  Through IANA, the IETF delegates unicast IP address and AS number ranges to the RIR system [RFC7020],[RFC7249].  Special address allocation, such a multicast and anycast addresses, often require coordination.  

Another example of IP addresses that are not administered by the

RIR system is Unique Local Addresses (ULAs) [RFC4193], where local

networks employ a prefix that is not intended to be routed on the

public Internet.  New special address allocations are added, from

time to time, related to the evolution of the standards.  In all

cases, these special assignments are listed in the IANA

registries.

 

* The IETF maintains sub-registries for special IPv4 and IPv6 assignments.  These are specified in [RFC3307], [RFC5771], and [RFC6890].  The IETF coordinates such assignments with the RIRs.  

* IETF standards changes may have impact on operations of RIRs and service providers.  A recent example is the extensions to BGP to carry the Autonomous System numbers as four-octet entities [RFC6793].  It is important to note that this change occurred out of operational necessity, and it demonstrated strong alignment between the RIRs and the IETF.  

>>> 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.

 

</pre>

IETF Response: The protocol parameters registries.

 

<pre>

>>> A description of how policy is developed and established and

>>> who is involved in policy development and establishment.

 

</pre>

IETF Response:

 

Policy for overall management of the registries is stated in

[RFC6220] and [RFC5226].  The first of these documents explains the

model for how the registries are to be operated, how policy is set,

and how oversight takes place.  RFC 5226 specifies the policies that

specification writers may employ when they define new protocol

registries in the "IANA Considerations" section of each

specification.  All policies at the IETF begin with a proposal in the

form of an Internet-Draft.  Anyone may submit such a proposal.  If

there is sufficient interest, the Internet Engineering Steering Group

may choose to create a working group or an Area Director may choose

to sponsor the draft.  In either case, anyone may comment on the

proposal as it progresses.  A proposal cannot be passed by the IESG

unless it enjoys sufficient community support as to indicate rough

consensus [RFC7282].  In each case, a "Last Call" is made so that

there is notice of any proposed change to a policy or process.

 

Anyone may comment during a Last Call.

>>>

>>> A description of how disputes about policy are resolved.

 

</pre>

IETF Response:

 

Most disputes are handled at the lowest level through the working

group and rough consensus processes.  Should anyone disagree with any

action, Section 6.5 of [RFC2026] specifies a multi-level conflict

resolution and appeals process that includes the responsible Area

Director, the IESG, and the IAB.  Should appeals be upheld, an

appropriate remedy is applied.  In the case where someone claims that

the procedures themselves are insufficient or inadequate in some way

to address a circumstance, one may appeal an IAB decision to the

Internet Society Board of Trustees.

>>>

>>> References to documentation of policy development and dispute

>>> resolution processes.

 

</pre>

IETF Response: As mentioned above, [RFC2026] Section 6.5 specifies a

conflict resolution and appeals process.  [RFC2418] specifies working

group procedures.  Note that both of these documents have been

amended in later RFCs as indicated in the [RFC-INDEX].  Please also

see the references at the bottom of this document.

>>>

>>> B. Oversight and Accountability

>>>

>>> This section should describe all the ways in which oversight is

>>> conducted over IANA functions operator's provision of the

>>> services and activities listed in Section I and all the ways in

>>> which IANA functions operator is currently held accountab le 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.

 

</pre>

IETF Response: the protocol parameters registries.

>>>

>>> If not all policy sources identified in Section II.A are

>>> affected, identify which ones are affected.

 

</pre>

IETF Response: all policy sources relating to the protocol parameters

registry are affected.

>>>

>>> 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.

 

</pre>

IETF Response:

 

The Internet Architecture Board (IAB) is an oversight body of the

IETF whose responsibilities include, among other things, confirming

appointment of IESG members, managing appeals as discussed above,

management of certain domains, including .ARPA [RFC3172], and general

architectural guidance to the broader community.  The IAB must

approve the appointment of an organization to act as IANA on behalf

of the IETF.  The IAB is also responsible for establishing liaison

relationships with other orgnaizations on behalf of the IETF. The

IAB's charter is to be found in [RFC2850].

 

The IAB members are selected and may be recalled through a Nominating

Committee (NOMCOM) process, which is described in [RFC3777].  This

process provides for selection of active members of the community who

themselves agree upon a slate of candidates.  Those candidates are

sent to the Internet Society Board of Trustees for confirmation.  In

general, members serve for two years.  The IAB selects its own chair.

 

The IAB provides oversight of the protocol parameters registries of

the IETF, and is responsible for selecting appropriate operator(s)

and related per-registry arrangements.  Especially when relationships

among protocols call for it, many registries are operated by, or in

conjunction with, other bodies.  Unless the IAB or IETF has concluded

that special treatment is needed, the operator for registries is

currently ICANN.

>>>

>>> 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.

 

</pre>

IETF Response:

 

A memorandum of understanding (MoU) between ICANN and the IETF

community has been in place since 2000.  It can be found in

[RFC2860].  The MoU defines the work to be carried out by the IANA

staff for the IETF and the Internet Research Task Force (IRTF), a

peer organization to the IETF that focuses on research.  Each year a

service level agreement is negotiated that supplements the MoU.

 

 

Day-to-day administration and contract management is the

responsibility of the IETF Administrative Director (IAD).  The IETF

Administrative Oversight Committee (IAOC) oversees the IAD.  IAOC

members are appointed by the Internet Society Board of Trustees, the

IAB, the IESG, and the NOMCOM [RFC4071].  The IAOC works with the

IANA functions operator to establish annual IANA performance metrics

and operational procedures, and the resulting document is adopted as

an supplement to the MoU each year [MOUSUP].  In accordance with

these supplements, an annual review is performed to ensure that

protocol parameter requests are being processed according to the

established policies.

 

To date there have been no unresolvable disputes or issues.  In the

unlikely event that a more difficult situation should arise, the IAOC

and the IAB would engage ICANN management to address the matter.  The

MoU also provides an option for either party to terminate the

arrangement with six months notice.  Obviously such action would only

be undertaken after serious consideration.

>>>

>>>  Jurisdiction(s) in which the mechanism applies and the legal

>>>  basis on which the mechanism rests.

 

</pre>

IETF Response

This mechanism is global in nature.  The current agreement does not

specify a jurisdiction.

>>>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

>>> 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.

 

</pre>

IETF Response:

 

No major changes are required, however, the IETF community has

regime.  Over the years since the creation of ICANN, the IETF, ICANN,

and IAB have together created a system of agreements, policies, and

oversight mechanisms that covers what is needed.

 

First and foremost, IANA protocol parameters registry updates will

continue to function day-to-day, as they have been doing for the last

decade or more.  The IETF community is quite satisfied with the

current arrangement with ICANN.  RFC 2860 remains in force and has

served the IETF community very well.  RFC 6220 has laid out an

appropriate service description and requirements.

 

To address issues raised by the IETF community relating to

intellectual property rights, the IAOC is asked to engage the

appropriate parties, both inside and outside the IETF, to make clear

that data in the protocol parameters registries is in the public

domain.

 

To address a desire by the IETF community to have mechanisms that

allow for additional dispute resolution between the IETF and the

current IANA protocol registries operator, the IAOC is asked to

necessary dispute resolution mechanisms that are mutually acceptable

to the parties.

 

To address concerns regarding appropriate contingencies to transition

to another operator, the IAOC is asked to conclude a supplemental

agreement that-

 

1.  maintains the IANA functions operator's obligations established

under C.7.3 and I.61 of the current IANA functions contract

between ICANN and the NTIA [NTIA-Contract]; and

 

2.  requires the transfer of any associated marks and identifiers to

 

 

Discussions during IETF 89 in London led to the following guiding

principles for IAB efforts that impact IANA protocol parameter

registries.  These principles must be taken together; their order is

not significant.

 

1.  The IETF protocol parameters registries function has been and

continues to be capably provided by the Internet technical community.

 

The strength and stability of the function and its foundation within

the Internet technical community are both important given how

critical protocol parameters are to the proper functioning of IETF

protocols.

 

We think the structures that sustain the protocol parameters

registries function needs to be strong enough that they can be

offered independently by the Internet technical community, without

the need for backing from external parties.  And we believe we

largely are there already, although the system can be strengthened

further, and continuous improvements are being made.

 

2.  The protocol parameters registries function requires openness,

transparency, and accountability.

 

Existing documentation of how the function is administered and

overseen is good [RFC2860], [RFC6220].  Further articulation and

clarity may be beneficial.  It is important that the whole Internet

community can understand how the function works, and that the

processes for registering parameters and holding those who oversee

the protocol parameters function accountable for following those

processes are understood by all interested parties.  We are committed

to making improvements here if necessary.

 

3.  Any contemplated changes to the protocol parameters registries

function should respect existing Internet community agreements.

 

The protocol parameters registries function is working well.  The

technical work to be carried out by the Internet Assigned Numbers

Authority on behalf of the Internet Engineering Task Force and the

Internet Research Task Force."  Any modifications to the protocol

parameters registries function should be made using the IETF process

to update RFC 6220 and other relevant RFCs.  Put quite simply:

evolution, not revolution.

 

4.  The Internet architecture requires and receives capable service

by Internet registries.

 

The stability of the Internet depends on capable provision of not

just IETF protocol parameters, but IP numbers, domain names, and

other registries.  Furthermore, DNS and IPv4/IPv6 are IETF-defined

protocols.  Thus we expect the role of the IETF in standards

development, architectural guidance, and allocation of certain name/

number parameters to continue.  IP multicast addresses and special-

use DNS names are two examples where close coordination is needed.

 

The IETF will continue to coordinate with ICANN, the RIRs, and other

parties that are mutually invested in the continued smooth operation

of the Internet registries.  We fully understand the need to work

together.

 

5.  The IETF will continue management of the protocol parameter

registry function as an integral component of the IETF standards

process and the use of resulting protocols.

 

RFC 6220 specifies the role and function of the protocol parameters

registry, which is critical to IETF standards processes and IETF

protocols.  The IAB, on behalf of the IETF, has the responsibility to

define and manage the relationship with the protocol registry

operator role.  This responsibility includes the selection and

management of the protocol parameter registry operator, as well as

management of the parameter registration process and the guidelines

for parameter allocation.

 

6.  The protocol parameters registries are provided as a public

service.

 

Directions for the creation of protocol parameters registries and the

policies for subsequent additions and updates are specified in RFCs.

 

The protocol parameters registries are available to everyone, and

they are published in a form that allows their contents to be

included in other works without further permission.  These works

include, but are not limited to, implementations of Internet

protocols and their associated documentation.

 

These principles will guide the IAB, IAOC, and the rest of the IETF

community as they work with ICANN to establish future IANA

performance metrics and operational procedures.

>>> 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:

 

>>>

>>>  o Description of operational requirements to achieve continuity

>>>   of service and possible new service integration throughout

>>>   the transition.

 

>>>  o Risks to operational continuity

>>>  o Description of any legal framework requirements in the

>>>   absence of the NTIA contract

>>>  o 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.

 

</pre>

IETF Response:

 

No structural changes are required.  The principles listed above will

guide IAB, IAOC, and the rest of the IETF community as they work with

ICANN to establish future IANA performance metrics and operational

procedures, as they have in the past.

 

As no services are expected to change, no continuity issues are

anticipated, and there are no new technical or operational methods

proposed by the IETF to test.  The IETF leadership, ICANN, and the

RIRs maintain an ongoing informal dialog to spot any unforeseen

issues that might arise as a result of other changes.

 

What is necessary as part of transition is the completion of

supplemental agreement(s) discussed in the previous section of this

RFP.

>>>

>>> V.  NTIA Requirements

>>>

>>> Additionally, NTIA has established that the transition proposal

>>> must meet the following five requirements:

 

>>>

>>> "Support and enhance the multistakeholder model;"

</pre>

IETF Response:

 

Everyone is welcome to participate in IETF activities.  The policies

and procedures are outlined in the documents we named above.  In-

person attendance is not required for participation, and many people

participate in email discussions that have never attended an IETF

meeting.  An email account is the only requirement to participate.

 

The IETF makes use of both formal and informal lines of communication

to collaborate with other organizations within the multistakeholder

ecosystem.

>>>

>>> "Maintain the security, stability, and resiliency of the

>>>  Internet DNS;"

</pre>

IETF Response:

 

The DNS relies on some of the IETF protocol parameters registries.

 

As the current IANA functions operator, ICANN performs its task very

Security, stability, and resiliency of the Internet DNS is best

protected by maintaining the current service in its current form.

>>>

>>> "Meet the needs and expectation of the global customers and

>>>  partners of the IANA services;"

</pre>

IETF Response:

 

Implementers and their users from around the world make use of the

IETF standards and the associated IANA protocol parameters

registries.  The current IANA protocol parameters registries system

is meeting the needs of these global customers.  This proposal

continues to meet their needs by maintaining the existing processes

that have served them well in the past.

>>>

>>>

>>> "Maintain the openness of the Internet."

</pre>

IETF Response:

 

 

This proposal maintains the existing open framework that allows

anyone to participate in the development of IETF standards, including

the IANA protocol parameters registries policies.  Further, an

implementer anywhere in the world has full access to the protocol

specification published in the RFC series and the protocol parameters

registries published at iana.org.  Those who require assignments in

the IANA protocol registries will continue to be able to do so, as

specified by the existing policies for those registries.

>>>

>>> VI.  Community Process

>>>

>>> This section should describe the process your community used for

>>> developing this proposal, including:

 

>>>

>>> o The steps that were taken to develop the proposal and to

>>>   determine consensus.

 

</pre>

IETF Response:

 

The IESG established the IANAPLAN working group to develop this

response.  Anyone was welcome to join the discussion and participate

in the development of this response.  An open mailing list

(ianaplan@ietf.org) was associated with the working group.  In

addition, IETF's IANA practices have been discussed in the broader

community, and all input is welcome.

>>>

>>> Links to announcements, agendas, mailing lists, consultations and

>>> meeting proceedings.

 

</pre>

IETF Response: [xxx to be completed in more detail]

The following list is not exhaustive, as there have been many open

discussions about this transition within the IETF community in the

past few months.

 

Creation of an open mailing list to discuss the transition:  http://w

ww.ietf.org/mail-archive/web/ietf-announce/current/msg12978.html

Announcement of a public session on the transition:  http://

www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html

Announcement by the IESG of the intent to form a working group:

 

http://www.ietf.org/mail-archive/web/ietf-announce/current/

msg13170.html

>>>

>>> An assessment of the level of consensus behind your community's

>>> proposal, including a description of areas of contention or

>>> disagreement.

 

</pre>

IETF Response: To be completed as the process progresses.

 

== 3.  IANA Considerations ==

This memo is a response a request for proposals.  No parameter

allocations or changes are sought.

 

== 4.  Security Considerations ==

While the IANA framework has shown strong resiliency, the IETF will

continue to work with all relevant parties to facilitate improvements

in our standards.

 

== 5.  Acknowledgments ==

This document does not define new processes, and so it seems we

acknowledge all of the preceding IAB members and members of the

community who developed the processes that we describe.  The initial

version of this document was developed collaboratively through both

the IAB IANA Strategy Program and the IETF IANAPLAN WG.  Particular

thanks go to Jari Arkko, John Klensin, Andrei Robachevsky, Andrew

Sullivan, Leslie Daigle, Marc Blanchet, Barry Leiba, Brian Carpenter,

Greg Wood, John Curran, Milton Mueller, Alissa Cooper, Andrei

Robachevsky, Miles Fidelman, and Richard Hill.

 

== 6.  Informative References ==

[METRICS]  , "Performance Standards Metrics Report", ,

<http://www.iana.org/performance/metrics>.

 

[MOUSUP]   , "Supplements to RFC 2860 (the Memorandum of

Understanding between the IETF and ICANN)", ,

<http://iaoc.ietf.org/contracts.html>.

 

[NTIA-Contract]

, "The NTIA Contract with ICANN", , <http://www.ntia.doc.gov/files/ntia/publications/sf_26_pg_1-2-final_award_and_sacs.pdf>.

 

[RFC-INDEX]

RFC Editor, , "Index of all Requests for Comments", RFC

Index, August 2014.

 

3", BCP 9, RFC 2026, October 1996.

 

Procedures", BCP 25, RFC 2418, September 1998.

 

the Internet Architecture Board (IAB)", BCP 39, RFC 2850,

May 2000.

 

Understanding Concerning the Technical Work of the

Internet Assigned Numbers Authority", RFC 2860, June 2000.

 

Requirements for the Address and Routing Parameter Area

Domain ("arpa")", BCP 52, RFC 3172, September 2001.

 

Addresses", RFC 3307, August 2002.

 

[RFC3595]  Wijnen, B., "Textual Conventions for IPv6 Flow Label", RFC

3595, September 2003.

 

Recall Process: Operation of the Nominating and Recall

Committees", BCP 10, RFC 3777, June 2004.

 

Administrative Support Activity (IASA)", BCP 101, RFC

4071, April 2005.

 

Addresses", RFC 4193, October 2005.

 

IANA Considerations Section in RFCs", BCP 26, RFC 5226,

May 2008.

 

IPv4 Multicast Address Assignments", BCP 51, RFC 5771,

March 2010.

 

[RFC6220]  McPherson, D., Kolkman, O., Klensin, J., Huston, G.,

Function of IETF Protocol Parameter Registry Operators",

RFC 6220, April 2011.

 

[RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",

RFC 6761, February 2013.

 

Autonomous System (AS) Number Space", RFC 6793, December

2012.

 

[RFC6852]  Housley, R., Mills, S., Jaffe, J., Aboba, B., and L. St.

Amour, "Affirmation of the Modern Paradigm for Standards",

RFC 6852, January 2013.

 

[RFC6890]  Cotton, M., Vegoda, L., Bonica, R., and B. Haberman,

"Special-Purpose IP Address Registries", BCP 153, RFC

6890, April 2013.

 

Internet Numbers Registry System", RFC 7020, August 2013.

 

[RFC7249]  Housley, R., "Internet Numbers Registries", RFC 7249, May

2014.

 

[RFC7282]  Resnick, P., "On Consensus and Humming in the IETF", RFC

7282, June 2014.

 

== NOTE: This section to be removed by RFC Editor at publication. ==

 

* A better description special registries and BGP ASNs.  

* Clarity on how the address space and ASNs are delegated.  

* Many editorials corrected.  

* Mention of the annual review as part of the SLAs.  

* Change about how overlap is presented.  

* A number of small wording changes based on feedback.  

* Front matter greatly reduced.  

* Appendices with charter and RFP added.  

* Jurisdiction text changed.  

* Proposed changes include supplemental agreement(s) to address jurisdiction, dispute resolution, and IPR, including names and marks.  

* Transition implications slightly modified to reference supplemental agreement.  

 

= Charter for the IANA Stewardship Transition Coordination Group V.10 (August 27, 2014) =

 

The IANA stewardship transition coordination group (ICG) has one

deliverable: a proposal to the U.S.  Commerce Department National

Telecommunications and Information Administration (NTIA) regarding

the transition of NTIA's stewardship of the IANA functions to the

global multi-stakeholder community.  The group will conduct itself

transparently, consult with a broad range of stakeholders, and ensure

that its proposals support the security and stability of the IANA

functions.

 

The group's mission is to coordinate the development of a proposal

among the communities affected by the IANA functions.  The IANA

functions are divided into three main categories: domain names,

number resources, and other protocol parameters.  The domain names

category falls further into the country code and generic domain name

sub-categories.  While there is some overlap among all of these

categories, each poses distinct organizational, operational and

technical issues, and each tends to have distinct communities of

interest and expertise.  For those reasons it is best to have work on

the three categories of IANA parameters proceed autonomously in

parallel and be based in the respective communities.

 

The IANA stewardship transition process is taking place alongside a

parallel and related process on enhancing ICANN accountability.

 

While maintaining the accountability of Internet identifier

governance is central to both processes, this group's scope is

focused on the arrangements required for the continuance of IANA

functions in an accountable and widely accepted manner after the

expiry of the NTIA-ICANN contract.  Nevertheless, the two processes

are interrelated and interdependent and should appropriately

coordinate their work.

 

The coordination group has four main tasks:

 

(i) Act as liaison to all interested parties, including the three

"operational communities" (i.e., those with direct operational

or service relationship with IANA; namely names, numbers,

protocol parameters). This task consists of:

 

:a. Soliciting proposals from the operational communities

:b. Soliciting the input of the broad group of communities affected by the IANA functions

 

(ii) Assess the outputs of the three operational communities for

compatibility and interoperability

 

(iii) Assemble a complete proposal for the transition

 

(iv) Information sharing and public communication

 

== Describing each in more detail: ==

 

===(i) Liaison===

 

====a. Solicit proposals====

 

The ICG expects a plan from the country code and generic name

communities (possibly a joint one), a plan from the numbers

community, and a plan from the protocol parameters community.

 

Members of the ICG will ensure that the communities from which they

are drawn are working on their part of the transition plans.  This

involves informing them of requirements and schedules, tracking

progress, and highlighting the results or remaining issues.  The role

of a coordination group member during this phase is to provide status

updates about the progress of his or her community in developing

their component, and to coordinate which community will develop a

transition proposal for each area of overlap (e.g., special-use

registry).

 

While working on the development of their proposals, the operational

communities are expected to address common requirements and issues

relating to the transition, in as far as they affect their parts of

the stewardship of IANA functions.

 

====b.  Solicit broader input====

 

The ICG is open for input and feedback from all interested parties.

 

While no set of formal requirements related to a transition proposal

will be requested outside the operational communities, everyone's

input is welcome across all topics.

 

The ICG expects that all interested parties get involved as early as

possible in the relevant community processes.  Input received