< draft-iab-iana-framework-01.txt   draft-iab-iana-framework-02.txt >
Internet Architecture Board(IAB) IAB Internet Architecture Board(IAB) IAB
Internet-Draft O. Kolkman, Ed. Internet-Draft
Intended status: Informational NLnet Labs Intended status: Informational O. Kolkman, Ed.
Expires: July 24, 2014 January 22, 2014 Expires: September 20, 2014 NLnet Labs
March 19, 2014
A Framework for the Evolution of the Internet Assigned Numbers A Framework for Describing the Internet Assigned Numbers Authority(IANA)
Authority(IANA) draft-iab-iana-framework-02
draft-iab-iana-framework-01
Abstract Abstract
This document provides a framework for describing the management of This document provides a framework for describing the management of
Internet registries managed by the Internet Assigned Numbers Internet registries managed by the Internet Assigned Numbers
Authority. It defines terminology describing the various roles and Authority. It defines terminology describing the various roles and
responsibilities associated with management of Internet registry responsibilities associated with management of Internet registry
functions. functions.
[ InternetGovtech@iab.org is the list which the IAB will be [ Note: This is a work in progress and documents the thoughts
monitoring for the discussion of this draft. See http://www.iab.org/ developed by the IAB in its IAB iana-evolution program ( http://
mailman/listinfo/internetgovtech for subscription details ] www.iab.org/activities/programs/iana-evolution-program/)
InternetGovtech@iab.org is the list which the IAB will be monitoring
for the discussion of this draft. See http://www.iab.org/mailman/
listinfo/internetgovtech for subscription details. ]
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 24, 2014. This Internet-Draft will expire on September 20, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Internet Registries and Interoperability on the Internet . 2 1.1. Internet Registries and Interoperability on the Internet 3
1.2. The IANA function and Internet Registries . . . . . . . . 3 1.2. The IANA function and Internet Registries . . . . . . . . 4
1.3. An IANA Framework . . . . . . . . . . . . . . . . . . . . 4 1.3. Framework for Internet Registries . . . . . . . . . . . . 5
2. Roles in Relation to Internet Registries . . . . . . . . . . . 5 2. Roles in Relation to Internet Registries . . . . . . . . . . 6
2.1. The Policy Development Role . . . . . . . . . . . . . . . 5 2.1. The Policy Role . . . . . . . . . . . . . . . . . . . . . 6
2.2. Implementation aspects . . . . . . . . . . . . . . . . . . 6 2.2. Evaluation Coordination Role . . . . . . . . . . . . . . 7
2.2.1. Evaluation Coordination Role . . . . . . . . . . . . . 6 2.3. Maintenance/Publication Role . . . . . . . . . . . . . . 8
2.2.2. Maintenance and Publication of Registry Content Role . 7 2.4. The Oversight Role . . . . . . . . . . . . . . . . . . . 8
2.3. The Oversight Role . . . . . . . . . . . . . . . . . . . . 7 3. Key principles of the IANA framework . . . . . . . . . . . . 9
3. Key principles of the IANA framework . . . . . . . . . . . . . 8 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. On Separation of the roles . . . . . . . . . . . . . . . 9
4.1. On Separation of the roles . . . . . . . . . . . . . . . . 8 4.2. On Delegation . . . . . . . . . . . . . . . . . . . . . . 10
4.2. On Accountability . . . . . . . . . . . . . . . . . . . . 8 4.3. Accountability . . . . . . . . . . . . . . . . . . . . . 10
4.3. On Delegation . . . . . . . . . . . . . . . . . . . . . . 9 4.4. On the Ability to create Internet Registries . . . . . . 11
4.4. On the Abbility to create Internet Registries . . . . . . 10 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5. On the relation to RFC6220 . . . . . . . . . . . . . . . . 10 5.1. Policy Examples . . . . . . . . . . . . . . . . . . . . . 11
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1.1. IETF Protocol Parameter Registries . . . . . . . . . 12
5.1. Policy Examples . . . . . . . . . . . . . . . . . . . . . 11 5.1.2. Number Resources . . . . . . . . . . . . . . . . . . 12
5.1.1. Policy Example 1 . . . . . . . . . . . . . . . . . . . 11 5.1.3. Domain Names . . . . . . . . . . . . . . . . . . . . 12
5.1.2. Policy Example 2 . . . . . . . . . . . . . . . . . . . 11 5.2. Evaluation Coordination Role Examples . . . . . . . . . . 13
5.1.3. Policy Example 3 . . . . . . . . . . . . . . . . . . . 12 5.2.1. IETF Protocol Parameters . . . . . . . . . . . . . . 13
5.2. Evaluation Coordination Role Examples . . . . . . . . . . 12 5.2.2. Nubmer Resources . . . . . . . . . . . . . . . . . . 13
5.2.1. Evaluation Example 1 . . . . . . . . . . . . . . . . . 12 5.2.3. Domain Names . . . . . . . . . . . . . . . . . . . . 13
5.2.2. Evaluation Example 2 . . . . . . . . . . . . . . . . . 12 5.3. Maintenance and Publication of Registry Content . . . . . 13
5.2.3. Evaluation Example 3 . . . . . . . . . . . . . . . . . 12 5.3.1. IETF Protocol Parameters . . . . . . . . . . . . . . 14
5.3. Maintenance and Publication of Registry Content . . . . . 13 5.3.2. Alternative publication mechanisms . . . . . . . . . 14
5.3.1. Maintenance Example 1 . . . . . . . . . . . . . . . . 13 5.4. Oversight Examples . . . . . . . . . . . . . . . . . . . 14
5.3.2. Maintenance Example 2 . . . . . . . . . . . . . . . . 13 5.4.1. IETF Protocol Parameters . . . . . . . . . . . . . . 14
5.4. Oversight Examples . . . . . . . . . . . . . . . . . . . . 13 5.4.2. Nubmer Resources . . . . . . . . . . . . . . . . . . 14
5.4.1. Oversight Example 1 . . . . . . . . . . . . . . . . . 13 5.4.3. Coordination - gTLDs vs special domain names . . . . 14
5.4.2. Oversight Example 2 . . . . . . . . . . . . . . . . . 13 5.4.4. Coordination - ccTLD Administration . . . . . . . . . 14
5.4.3. Oversight Example 3 . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5.4.4. Oversight Example 4 . . . . . . . . . . . . . . . . . 14 7. Contributors and Acknowledgemetns . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considderations . . . . . . . . . . . . . . . . . . . . 15
7. Contributors and Acknowledgemetns . . . . . . . . . . . . . . 14 9. Informative References . . . . . . . . . . . . . . . . . . . 15
8. IANA Considderations . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Document Editing Details . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 A.1. Version Information . . . . . . . . . . . . . . . . . . . 18
Appendix A. Document Editing Details . . . . . . . . . . . . . . . 15 A.1.1. draft-iab-iana-framework-01 -> draft-iab-iana-
Appendix A.1. Version Information . . . . . . . . . . . . . . . 16 framework-02 . . . . . . . . . . . . . . . . . . . . 18
Appendix A.1.1. draft-kolkman-iana-framework-00 . . . . . . . 16 A.1.2. draft-iab-iana-framework-00 -> draft-iab-iana-
Appendix A.1.2. draft-kolkman-iana-framework-00 -> draft-iab- framework-01 . . . . . . . . . . . . . . . . . . . . 18
iana-framework-00 . . . . . . . . . . . . . . 16 A.1.3. draft-kolkman-iana-framework-00 -> draft-iab-iana-
Appendix A.1.3. draft-iab-iana-framework-00 -> draft-iab-iana- framework-00 . . . . . . . . . . . . . . . . . . . . 19
framework-01 . . . . . . . . . . . . . . . . 16 A.1.4. draft-kolkman-iana-framework-00 . . . . . . . . . . . 19
Appendix A.1.4. TODO . . . . . . . . . . . . . . . . . . . . 17 A.1.5. TODO . . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix A.2. Subversion information . . . . . . . . . . . . . 17 A.2. Subversion information . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
1.1. Internet Registries and Interoperability on the Internet 1.1. Internet Registries and Interoperability on the Internet
Internet registries hold identifiers consisting of constants and
other well-known values used by Internet protocols. Such values
define a common vocabulary that protocols understand when
communicating with each other. For example, the TCP port number of
"80" is globally understood to denote "http" service. Almost every
protocol in existence makes use of registries in some form.
Internet registries are critical to the operation of the Internet. Internet registries are critical to the operation of the Internet,
They are needed to record the definitive value and meaning of since they provide a definitive record of the value and meaning of
identifiers that protocols use when communicating with each other. identifiers that protocols use when communicating with each other.
Management of Internet registries must be done in a predictable, Almost every Internet protocol makes use of registries in some form.
stable and secure manner in order to ensure that protocol identifiers At the time of writing, the Internet Assigned Numbers Authority
have consistent meanings and interpretations across all (IANA) maintains over one thousand protocol parameter registries.
implementations and deployments.
Protocol identifier values can be numbers, strings, addresses, and so Management of Internet registries must be predictable, stable and
on. They are uniquely assigned for one particular purpose or use. secure, in order to ensure that protocol identifiers have consistent
They can be maintained in centrally maintained lists (such as, for meanings and interpretations across all implementations and
instance, lists of cryptographic algorithms in use in a particular deployments. For example, TCP port number 80 is globally understood
protocol) or hierarchically allocated and assigned by separate to denote the "http" service.
entities at different points in the hierarchy (such as for IP
addresses and domain names). At the time of writing, the Internet Internet registries hold identifiers consisting of constants and
Assigned Numbers Authority (IANA) maintains over one thousand other well-known values used by Internet protocols. These values can
protocol parameter registries. be numbers, strings, addresses, etc. They are uniquely assigned for
one particular purpose or use. Identifiers can be maintained in
within a central list (e.g. a list of cryptographic algorithms for
use in a particular protocol) or they can be hierarchically allocated
and assigned by separate entities at different points in the
hierarchy (such as for IP addresses and domain names).
Stable and predictable assignment and registration of protocol Stable and predictable assignment and registration of protocol
identifiers for Internet protocols is of great importance to many identifiers for Internet protocols is of great importance to many
stakeholders, including developers, vendors, and customers, as well stakeholders, including developers, vendors, and customers, as well
as users of devices, software, and services on the Internet. These as users of devices, software, and services on the Internet. These
stakeholders use and depend on registries and implicitly trust the stakeholders use and depend on registries and implicitly trust the
registry system to be stable and predictable. The registry system is registry system to be stable and predictable. The registry system is
built on trust and mutual cooperation; the use of the registries is built on trust and mutual cooperation; the use of the registries is
voluntary and is not enforced by mandates or certification policies. voluntary and is not enforced by mandates or certification policies.
While the use of registries is voluntary, it is noted that the
success of the Internet (e.g. as an enabler of social and economic
development) does create enormous pressure to utilize Internet
protocols, and hence the protocol registries and their associated
policies should be developed in a transparent manner which is open to
all interested parties.
Stability and consistency of Internet registries is achieved through Stability and consistency of Internet registries is achieved through
the definition of appropriate and clear policies for making additions the definition of appropriate and clear policies for making additions
to or updating existing entries. Such policies must take into to or updating existing entries. Such policies must take into
account the technical and operational properties of the technology account the technical and operational properties of the technology
that makes use of the registries. At the same time, it must be that makes use of the registries. At the same time, it must be
possible to evolve the systems and policies for managing registry possible to evolve the systems and policies for managing registry
contents as the Internet itself evolves. contents as the Internet itself evolves. This description of
responsibilities, entities, and functions within the scope of IANA
serves as an aid for a structured approach to the potential evolution
of the Internet Registries model.
1.2. The IANA function and Internet Registries 1.2. The IANA function and Internet Registries
The Internet Engineering Task Force (IETF) and its predecessors have The Internet Engineering Task Force (IETF) and its predecessors have
traditionally separated the publication mechanism of its protocol traditionally separated the publication mechanism of its protocol
specifications, published in immutable RFCs, from the registries specifications, published in immutable Request for Comments (RFCs),
containing protocol parameters. The latter is maintained by a set of from the registries containing protocol parameters. The latter is
functions traditionally known collectively as the Internet Assigned maintained by a set of functions traditionally known collectively as
Numbers Authority (IANA). Dating back to the somewhat before the the Internet Assigned Numbers Authority (IANA). Dating back to the
earliest days of the Internet, the specification publication function somewhat before the earliest days of the Internet, the specification
and the registry maintenance functions were tightly coupled: Jon publication function and the registry maintenance functions were
Postel of the Information Sciences Institute (ISI) of the University tightly coupled: Jon Postel of the Information Sciences Institute
of Southern California (USC) was responsible for both the RFC (ISI) of the University of Southern California (USC) was responsible
publications and the IANA function. However, this tight coupling was for both the RFC publications and the IANA function. However, this
never a requirement and indeed, today the RFC Editor and IANA tight coupling was never a requirement. Indeed, today the RFC Editor
function are contracted to different entities. (The RFC publication and IANA function are contracted to different entities. (The RFC
process and the IANA protocol parameter policy development process publication process and the IANA protocol parameter policy
and oversight remain closely coupled. For instance,one of the development process and oversight remain closely coupled. For
responsibilities of the IAB is oversight over the RFC Series and IANA example, the Internet Architecture Board (IAB) has oversight
[RFC2850] ) responsibilities over the both RFC Series and IANA [RFC2850].)
One way to approach Internet Registry Management is to examine the One way to approach Internet Registry Management is to examine the
what, why, who and how. The Internet or IANA Registries are tables what, why, who and how. Internet Registries are tables with
with assignments and allocations of values (the What), established by assignments and allocations of values (the 'what'), established by
explicit directions contained within Request for Comment (RFC) explicit directions contained within RFC documents (the 'why'). The
documents (the Why). The framework herein applies to individual framework described in this document applies to individual
registries. However Internet registries are colloquially grouped registries. These registries are colloquially grouped into 3
into 3 classes: Names, Numbers, and IETF Protocol Parameters. The classes: Names, Numbers, and IETF Protocol Parameters. The framework
framework applies, with some nuance, to all registries, regardless of applies, with some nuance, to all registries, regardless of their
their class. class. Within the context of this document the term "Internet
registries" is used for those the registries that are currently
organized as Domain Names, Number Resources, and IETF Protocol
Parameter registries.
In this framework we identify major 4 roles: The Policy, The One of the nuances that come into play is that some protocol
Oversight, the Evaluation Coordination, and Maintenance and parameters within these classes are "general use", and registry
Publication Roles (the latter two are both both implementation values assigned upon request to specific parties in accordance with
aspects). The entities in those roles can be interpreted as 'the who' the registry policy. Such assignments are generally unique in
while their collective responsibilities determine 'the how'. nature, i.e. only one party is associated with each general- purpose
registry entry. Coordination (or automation) is necessary to provide
uniqueness of assignments in each registry, but it is particularly
important in the general purpose registries given the large number of
assignments involved. Several of the general purpose registries
(DNS, IPv4, IPv6, ASNs) have been delegated to parties which are
believed to be reasonably representative of the communities dependent
upon those registries (e.g. ccTLD, and Regional Internet Registries).
Normally we use the term IANA for the set of functions with specific In this framework we identify major four roles: The Policy, The
responsibilities within the context of Internet Registries (mainly Oversight, the Evaluation Coordination, and Maintenance/Publication
those under Implementation Aspects below). In this document we use Roles (the latter two are both both implementation aspects). The
the term IANA or IANA function(s) independent of the entities that entities that perform each of these roles can be interpreted as 'the
implement those functions (the Who). Currently, according to the who' while the ways in which they carry out their roles determine
Memorandum of Understanding[RFC2860], the maintenance, implementation 'the how'.
and publication of most of the IETF protocol Registries is performed
by the Internet Corporation for Assigned Names and Numbers (ICANN). Within the IETF, the term "IANA" is often used to describe functions
belonging to the Evaluation Coordination and Maintenance/Publication
roles (as described below). In this document we use the term IANA or
IANA function(s) independent of the entities that implement those
functions (the 'who'). Currently, according to the Memorandum of
Understanding[RFC2860], the maintenance, implementation and
publication of most of the IETF protocol parameter registries are
performed by the Internet Corporation for Assigned Names and Numbers
(ICANN).
1.3. Framework for Internet Registries
1.3. An IANA Framework
This document provides a framework for describing the management of This document provides a framework for describing the management of
Internet Registries as they are currently implemented. It defines Internet Registries as they are currently implemented. In Section 2
terminology describing the various roles and responsibilities it defines terminology describing the various roles and
associated with those roles in Section 2. In Section 3 we enumerate a responsibilities associated with those roles. In Section 3 we
few key principles for the implementation of the Framework. In enumerate a few key principles for the implementation of the
Section 4 we discuss some of the issues that came up during the framework. In Section 4 we discuss the existing context for these
development of the draft. Finally, in Section 5 we provide a number principles and other features of the framework. Finally, in
of examples on how the framework applies today. Those sections Section 5 we provide a number of examples on how the framework
intend to demonstrate that the framework can be applied to the applies today. The examples demonstrate how the framework is applied
situation today, albeit with the necessary nuance, and that it is a to the situation today and its utility going forward.
helpful concept going forward.
Although this document can be read independent of [RFC6220] and This document may be read independent of [RFC6220] and [RFC7020].
[RFC7020] -- which document the requirements specific to a subset of Those documents identify the specific requirements for the IETF
all current IANA function Internet registries, namely the IETF Protocol Parameter registries and the Internet Numbers Registry
protocol parameter registries and the Internet Numbers Registry System. As such, they provide context and examples for some of the
System respectively --, those RFCs provide context and example of the subject matter of this document. Those requirements apply only to
subject matter of this document. those subsets of the current collection of IANA function Internet
registries.
The authors are aware that this framework uses fewer, slightly
different, and more generic terms to describe the various roles than
[RFC6220]. [RFC6220] is a document that specifically pertains to the
IETF protocol parameter registries.
For instance, [RFC6220] section 2.1 "Protocol Parameter Registry
Operator Role" describes the full set of responsibilities for the
operator(s) of the IETF Protocol Parameter registries. These
responsibilities map to the Implementor aspects in Section 2.2 and
Section 2.3 below. [RFC6220] also describes the role of the IETF
Administrative Oversight Committee (IAOC) and IETF Trust. These
bodies have specific responsibilities in the wider IETF and are
responsible for contracting and IPR respectively. Within this
framework they should be considered part of the 'oversight role'.
The words must, should, shall, required, may and such should not be The words must, should, shall, required, may and such should not be
interpreted as normative language as defined in [RFC2119], but in interpreted as normative language as defined in [RFC2119], but in
their plain English meaning. their plain English meaning.
2. Roles in Relation to Internet Registries 2. Roles in Relation to Internet Registries
In this section we discuss the roles relevant to Internet Registries In this section we discuss the roles relevant to Internet Registries
in terms of an abstract registry that is defined as part of a in terms of an abstract registry that is defined as part of an
arbitrary technical specification. Registry management involves 3 arbitrary technical specification.
roles. First, a policy development role that defines the purpose of
the registry and the process and requirements for making additions or
updates. Second, roles that refer to the operational process for
processing change requests to a registry and for publishing its
contents, both implementation aspects. Finally, an oversight role
that refers to a high-level responsibility for ensuring that the
other two roles are operating satisfactorily and stepping in if
significant changes are needed in the policies or implementation of a
registry. Each of these roles is described in more detail in the
following subsections.
2.1. The Policy Development Role Registry management involves 4 roles. First, a policy development
role that defines the purpose of the registry and the process and
requirements for making additions or updates. Second, roles that
refer to the operational process for processing change requests to a
registry and for publishing its contents, both implementation
aspects. Finally, an oversight role that refers to a high-level
responsibility for ensuring that the other two roles are operating
satisfactorily and stepping in if significant changes are needed in
the policies or implementation of a registry. Each of these roles is
described in more detail in the following subsections.
2.1. The Policy Role
Description: Description:
Registries may need to have additional values added, or an existing Registries may need to have additional values added, or an existing
entry may need to be removed, clarified, or updated in some manner. entry may need to be removed, clarified, or updated in some manner.
The policy development role creates the registry and defines the The Policy Role creates the registry and defines the policies that
policies that describes who can make updates or additions, what sort describes who can make updates or additions, what sort of review (if
of review (if any) is needed, the conditions under which update any) is needed, the conditions under which update requests would
requests would normally be granted or when they might not, the normally be granted or when they might not, the security requirements
security requirements of these interactions, etc. The entity of these interactions, etc. The entity performing this role may
performing this role may delegate its policy responsibilities for delegate its policy responsibilities for part or all of the
part or all of the parameters within the registry. Concequently, in parameters within the registry. Consequently, in this document the
this document the word "policy" is used to refer to a specific course word "policy" is used to refer to a specific course or principle of
or principle of action for administration of a technical resource action for administration of a technical resource maintained within
maintained within specific registries" specific registries.
Key Responsibilities: Key Responsibilities:
The policy development role refers to the creation of the governing The Policy Role refers to the creation of the governing policies that
policies that define how and when a registry can be updated or define how and when a registry can be updated or modified.
modified.
Primary Output: Primary Output:
A set of policies by which registries can be populated. A set of policies by which registries can be populated.
2.2. Implementation aspects 2.2. Evaluation Coordination Role
The implementation aspects refer to the actual day-to-day operation
of a registry in terms of servicing requests for registry additions
or updates and publishing the contents of the registry. These roles
implement processes that abide by the policies as defined by the
policy development role. Two distinct roles responsible for
implementation aspects can be identified: Evaluation Coordination,
and the Maintenance and Publication of Registry Content. We discuss
these Roles separately.
2.2.1. Evaluation Coordination Role
Evaluation Role for short. The Evaluation Coordination Role and the Maintenance/Publication Role
(below) comprise the actual day-to-day operation of a registry in
terms of servicing requests for registry additions or updates and
publishing the contents of the registry. These roles implement
processes that abide by the policies as defined by the Policy Role.
Key Responsibility: Key Responsibility:
Coordinate, operate, and process the timely evaluation of Coordinate, operate, and process the timely evaluation of
registration requests based on policies set by the Policy Role. registration requests based on policies set by the Policy Role.
Primary Output: Primary Output:
A smoothly functioning system in which requests for registry updates A smoothly functioning system in which requests for registry updates
are submitted and are evaluated and processed in a manner consistent are submitted and are evaluated and processed in a manner consistent
with the policy guidance with the results recorded and published as with the policy guidance with the results recorded and published as
appropriate. In some cases, the evaluation of requests is a appropriate. In some cases, the evaluation of requests is a
straightforward task requiring little subjective evaluation, whereas straightforward task requiring little subjective evaluation, whereas
in other cases evaluation is more complex and requires subject matter in other cases evaluation is more complex and requires subject matter
experts as defined by the relevant policy guidance. experts as defined by the relevant policy guidance.
Relation to other roles and activities: Relation to other roles and activities:
The output of the evaluations is input to the process of assignment, The output of the evaluations is input to the process of assignment,
delegation, and/or population of the registries as performed by the delegation, and/or population of the registries as performed by the
entity in the Maintenance Role (Section 2.2.2). The evaluations are entity in the Maintenance/Publication Role (Section 2.3). The
performed based on the policies as defined by the Policy role. The evaluations are performed based on the policies as defined by the
coordination of the evaluation is different from the evaluation of a Policy Role. The coordination of the evaluation is different from
request itself: The Evaluation Role handles the request for the evaluation of a request itself: the Evaluation Coordination Role
allocation or maintenance of a record and may, under guidance of and handles the request for allocation or maintenance of a record and
in coordination with the policy role, delegate the actual evaluation may, under guidance of and in coordination with the entity fulfilling
to a third party. the Policy Role, delegate the actual evaluation to a third party.
2.2.2. Maintenance and Publication of Registry Content Role
Maintenance Role for short. 2.3. Maintenance/Publication Role
Key Responsibility: Key Responsibility:
The maintenance of the registries content: allocating or assigning The maintenance of the registries' content: allocating or assigning
parameters after positive evaluation and based on established parameters after positive evaluation and based on established
policies, keeping appropriate record of transactions, and making the policies, keeping appropriate record of transactions, and making the
registries publicly available. registries widely and freely available to the extend possible, to
encourage protocol usage in conformance with the specifications.
Primary Output: Primary Output:
Easy and convenient access to registry contents, with additions and Easy and convenient access to registry contents, with additions and
updates appearing in a timely manner. updates appearing in a timely manner.
Note: Note:
Registry maintenance and publication are strictly mechanical Registry maintenance and publication are strictly mechanical
functions. In practice the entity that performs those functions will functions. In practice the entity that performs those functions will
often perform some or all of the responsibilities of the Policy often perform some or all of the responsibilities of the Evaluation
Evaluation Coordination. For instance, verification that an Coordination Role. For instance, verification that an application/
application/registration request is correct is a Policy Evaluation registration request is correct is an Evaluation Coordination
responsibility that can reasonably be explicitly assigned to the responsibility that can reasonably be explicitly assigned to the
entity performing the IANA function by the entity that performs the entity performing the Maintenance/Publication Role by the entity that
Policy Development Role. performs the Policy Development Role while evaluation of technical
content is usually delegated to technical experts.
2.3. The Oversight Role 2.4. The Oversight Role
Description: Description:
The oversight role refers to a high-level responsibility for ensuring The oversight role refers to a high-level responsibility for ensuring
that the other two roles are operating satisfactorily, stepping in if that the other three roles are operating satisfactorily. Oversight
significant changes are needed in the policies or implementation of a involves stepping in if significant changes are needed in the
policies, evaluation coordination, maintenance, or publication of a
registry. registry.
Key Responsibility: Key Responsibility:
Ensure that policies and the implementation of registries are aligned Ensure that policies and the implementation of registries are aligned
in a way that supports the coherent long-term development and use of in a way that supports the coherent long-term development and use of
shared Internet resources. Coordinate with entities with similar shared Internet resources. Coordinate with entities with similar
roles for other registries. roles for other registries.
The oversight role is normally isolated with respect to the actual The oversight role is normally isolated from policy development.
policy development. That said, it may serve to resolve appeals or That said, the entity performing the Oversight Role may serve to
ratify developed policies. resolve appeals related to policies or ratify developed policies.
3. Key principles of the IANA framework 3. Key principles of the IANA framework
Any IANA framework should be implementable with the following key The following key principles underscore the successful functioning of
principles in mind. the framework:
Stable and Predictable: Stable and Predictable implementation of the Separation of Roles: The Policy, Evaluation Coordination,
Internet Registries Function is important for establishing global Maintenance/Publication, and Oversight roles should be separate or
trust. separable. A clear distinction between the roles enhances the
transparency and makes it clearer who is accountable to whom.
Accountability and transparency: Oversight, implementation, and Delegation: It should be possible to delegate any of the roles for
policy development roles are accountable to the materially registries or parts thereof.
concerned parties and the wider community. Not all roles may be
directly accountable to the wider community, in practice the
oversight role has responsibility for stewardship of the wider
community. By implication the oversight role must maintain the
highest possible standards of transparency and be open to input
and review.
Separation of Roles: The oversight, policy development, and Accountability and transparency: The entities fulfilling the roles
implementation roles should be separate or separable. A clear are accountable to the materially concerned parties and the wider
distinction between the roles enhances the transparency and makes community. The entities fulfilling the Oversight Role are
it clearer who is accountable to who. directly accountable to the wider community, although not all of
the entities fulfilling the other roles must be. By implication,
the entities fulfilling Oversight Role must maintain the highest
possible standards of transparency and be open to input and
review.
Delegation: It should be possible to delegate any of the roles Stable and Predictable: Stable and predictable implementation of the
(policy, implementation, or oversight) for registries or parts Internet registries function is important for establishing global
thereof. trust.
4. Discussion 4. Discussion
4.1. On Separation of the roles 4.1. On Separation of the roles
For many registries there is a de-facto separation of the Policy For many registries there is a de-facto separation of the Policy Role
Development and the Evaluation coordination that takes place at and the Evaluation Coordination Role that takes place at
implementation. While this has never been an explicit requirement, implementation. While this has never been an explicit requirement,
it seems that splitting those roles can surface a lack of clarity in it seems that splitting those roles can expose instances where
the policies. In addition, having the policy setting, oversight and policies lack of clarity, which provides helpful feedback to allow
evaluation roles separated prevents the evaluation role from being those policies to be improved. In addition, having the Policy,
burdened with perceptions of favoritism and unfairness. Oversight and the Evaluation Coordination Roles separated prevents
the risks of the Evaluation Coordination Role from being burdened
4.2. On Accountability with (perceptions of) favoritism and unfairness.
Any entity performing one of the roles defined in this framework is
to be held accountable for its responsibilities. Accountability of
each entity needs to be expressed in terms of 'who' and 'how'; to who
is the entity accountable and by which mechanisms is the entity being
held accountable. In other words registry policy development and
registry operations need to be "accountable" to the affected
community.
In practice accountability mechanisms may be defined by memoranda of
understanding or through contractual service level agreements (SLA)
between implementing entities and the oversight body while the
oversight bodies are being held accountable through community review
mechanisms, for instance through recall and appeal processes.
For example: For protocol parameters the general oversight over the
IANA function is performed by the IAB as a chartered responsibility
from [RFC2850] (also see Section 5.4). In addition the IAOC, a body
responsible for IETF administrational and financial matters,
[RFC4071] maintains an SLA with ICANN, thereby specifying the
operational requirements with respect to the the coordination of
evaluation, and the maintenance and publication of the registries.
Both the IAB and the IAOC are accountable to the larger Internet
community and are being held accountable through the IETF Nomcom
process [BCP10].
4.3. On Delegation 4.2. On Delegation
Most, if not all, protocol parameter registries were created by the Most, if not all, protocol parameter registries were created by the
IETF or its predecessors. Today, most IETF protocols registries are IETF or its predecessors. Today, most IETF protocols paramaters
maintained by the IANA at ICANN. However, nothing in this framework registries are maintained by the IANA at ICANN. However, nothing in
prohibits the delegation of the oversight, policy, evaluation, or this framework prohibits the delegation of the Oversight, Policy,
maintenance role (or any combination of these) of specific protocol Evaluation Coordination, or Maintenance/Publication role (or any
parameter registries to other organizations. In some circumstances, combination of these) of specific protocol parameter registries to
that may be desirable and allow improved registry management for the other organizations. In some circumstances, that may be desirable
good of the global Internet community. and allow improved registry management for the good of the global
Internet community.
Delegation of an IANA registry may be desirable for several reasons, Delegation of an IANA registry may be desirable for several reasons,
including support for more inclusive registry policy development, including support for more inclusive registry policy development,
distributing registry operations globally, and accommodating public distributing registry operations globally, and accommodating public
policy considerations in registry management. While delegation of an policy considerations in registry management. While delegation of an
IANA registry in these situations can improve the registry service IANA registry in these situations can improve the registry service
received by the global Internet community, it is not guaranteed to do received by the global Internet community, it is not guaranteed to do
so and hence it is incumbent upon the IAB to have clear guidelines so and hence it is incumbent upon the IAB to have clear guidelines
for successful IANA registry delegation. Such guidelines are out of for successful IANA registry delegation. Such guidelines are out of
scope for this document. scope for this document.
skipping to change at page 10, line 21 skipping to change at page 10, line 43
"Note that (a) assignments of domain names for technical uses (such "Note that (a) assignments of domain names for technical uses (such
as domain names for inverse DNS lookup), (b) assignments of as domain names for inverse DNS lookup), (b) assignments of
specialised address blocks (such as multicast or anycast blocks), and specialised address blocks (such as multicast or anycast blocks), and
(c) experimental assignments are not considered to be policy issues (c) experimental assignments are not considered to be policy issues
[...]". These special-purpose names and addresses are assigned in [...]". These special-purpose names and addresses are assigned in
the same manner as protocol parameters except that coordination is the same manner as protocol parameters except that coordination is
needed during policy setting and actual assignment of the values. needed during policy setting and actual assignment of the values.
The oversight bodies may facilitate the coordination. Also see The oversight bodies may facilitate the coordination. Also see
Policy Examples 2 and 3 in Section 5.1. Policy Examples 2 and 3 in Section 5.1.
4.4. On the Abbility to create Internet Registries 4.3. Accountability
Any entity performing one of the roles defined in this framework is
to be held accountable for its responsibilities. Accountability of
each entity needs to be expressed in terms of 'who' and 'how'; to who
is the entity accountable and by which mechanisms is the entity being
held accountable. In other words registry policy development and
registry operations need to be "accountable" to the affected
community.
In practice accountability mechanisms may be defined by memoranda of
understanding or through contractual service level agreements (SLA)
between implementing entities and the oversight body while the
oversight bodies are being held accountable through community review
mechanisms, for instance through recall and appeal processes.
For example: For protocol parameters the general oversight over the
IANA function is performed by the IAB as a chartered responsibility
from [RFC2850] (also see Section 5.4). In addition the IAOC, a body
responsible for IETF administrational and financial matters,
[RFC4071] maintains an SLA with ICANN, thereby specifying the
operational requirements with respect to the coordination of
evaluation, and the maintenance and publication of the registries.
Both the IAB and the IAOC are accountable to the larger Internet
community and are being held accountable through the IETF Nomcom
process [BCP10].
Accountability mechanisms can vary depending upon the actual
distribution of responsibilities (i.e.: how much is separated, how
much is delegated).
4.4. On the Ability to create Internet Registries
As with the IETF and the corresponding IANA Protocol registries, As with the IETF and the corresponding IANA Protocol registries,
other standards bodies (and other institutions) have long histories other standards bodies (and other institutions) have long histories
of defining and creating registries and the parameters, tables, and of defining and creating registries and the parameters, tables, and
other values that make them up. Those normal practices may obviously other values that make them up. Those normal practices may obviously
extend to registries and their contents for use on the Internet. extend to registries and their contents for use on the Internet.
This document does not prescribe how those registries are governed. This document does not prescribe how those registries are governed.
Within the context of this document the term Internet Registries is
used for those the registries that are currently organized as Domain
Names, Number Resources, and IETF Protocol Parameter registries.
The (wider) IETF has the authority to create new IETF Protocol The (wider) IETF has the authority to create new IETF Protocol
Parameter registries as described in [RFC6220]. The IETF also has Parameter registries as described in [RFC6220]. The IETF also has
the authority to create registries that pertain to the Domain Name the authority to create registries that pertain to the Domain Name
System, but only for specify technical use [RFC6761]. Finally the System, but only for specify technical use [RFC6761]. Finally the
IETF has the (exclusive) authority to make technical assignment for IETF has the (exclusive) authority to make technical assignment for
Number Resources out of the currently reserved address space Number Resources out of the currently reserved address space
([RFC2860] and [RFC4291]). ([RFC2860] and [RFC4291]).
4.5. On the relation to RFC6220
The authors are aware that this framework uses less, slightly
different, and more generic terms to describe the various roles than
[RFC6220]. [RFC6220] is a document that specifically pertains to the
IETF protocol parameter registries.
For instance, [RFC6220] section 2.1 "Protocol Parameter Registry
Operator Role" describes the full set of responsibilities for the
operator(s) of the IETF Protocol Parameter registries. These
responsibilities map to the Implementor aspects in Section 2.2 above.
[RFC6220] also describes the role of the IETF Administrative
Oversight Committee (IAOC) and IETF Trust. These bodies have
specific responsibilities in the wider IETF and are responsible for
contracting and IPR respectively. Within this framework they should
be considered part of the 'oversight role'.
5. Examples 5. Examples
5.1. Policy Examples 5.1. Policy Examples
Not coincidentally, the following 3 examples map to how the IANA Not coincidentally, the following 3 examples map to how the IANA
registration functions are currently organized: IETF Protocol registration functions are currently organized: IETF Protocol
Parameter Registries, Number Resources and Domain Names. Parameter Registries, Number Resources and Domain Names.
5.1.1. Policy Example 1 5.1.1. IETF Protocol Parameter Registries
The IETF, through the IESG (see [RFC6220] section 2.3), acts in this The IETF, through the IESG (see [RFC6220] section 2.3), acts in this
role when in the "IANA Considerations" sections of its RFCs it role when in the "IANA Considerations" sections of its RFCs it
specifies the creation of a new registry, specifies initial entries, specifies the creation of a new registry, specifies initial entries,
and specifies a policy for adding additional entries to the registry and specifies a policy for adding additional entries to the registry
in the future. [RFC5226] provides guidance and terminology that has in the future. [RFC5226] provides guidance and terminology that has
proven useful within the IETF for describing common policies for proven useful within the IETF for describing common policies for
managing its registries. Those terms include "Private Use", managing its registries. Those terms include "Private Use",
"Hierarchical allocation", "First Come First Served", "Expert "Hierarchical allocation", "First Come First Served", "Expert
Review", "Specification Required", "IESG Approval", "IETF Consensus", Review", "Specification Required", "IESG Approval", "IETF Consensus",
and "Standards Action". The IETF uses these and, if needed, other and "Standards Action". The IETF uses these and, if needed, other
templates to define the policy through which registries are templates to define the policy through which registries are
populated. populated.
5.1.2. Policy Example 2 5.1.2. Number Resources
IP address allocation and the associated policy development is
distributed too. For instance, the IETF has defined an IPv6 address
range called unicast addresses. For a fraction of that address range
ICANN has been delegated change control (see [RFC3513] section 4 for
details and [GlobAddrPol] for examples). The change control is
further delegated to the Regional Internet Registries (RIRs) which,
guided by policies set by the regional communities, delegate change
control even further e.g., to Local Internet Registries.
5.1.3. Domain Names
The Domain Name System (DNS) protocol allows for hierarchical The Domain Name System (DNS) protocol allows for hierarchical
maintenance of the domain name registries, and publication thereof. maintenance of the domain name registries, and publication thereof.
ICANN is currently responsible for change control at the root zone ICANN is currently responsible for change control at the root zone
which includes setting and maintaining policies for that zone. which includes setting and maintaining policies for that zone.
Change control, policy control, and publication authority follows the Change control, policy control, and publication authority follows the
DNS hierarchy; although ICANN is the authoritative entity in the DNS hierarchy; although ICANN is the authoritative entity in the
policy role for the root zone, it is not authoritative for all policy role for the root zone, it is not authoritative for all
domains below the root. For example the IETF sets the policy for domains below the root. For example the IETF sets the policy for
determining which names are allocated in the ietf.org zone. For determining which names are allocated in the ietf.org zone. For
country code top-level domains (ccTLD) the policies are set by the country code top-level domains (ccTLD) the policies are set by the
ccTLD registry in coordination with local community, local ccTLD registry in coordination with local community, local
regulator(s), and/or other national bodies. Even the policy for regulator(s), and/or other national bodies. Even the policy for
assignment of names within the root is subject nuance. For instance, assignment of names within the root is subject to nuances. For
ICANN has reserved two letter top-level domains for the use as instance, ICANN has reserved two letter top-level domains for the use
country and territory code Top Level Domains (ccTLDs). The assignment as country and territory code Top Level Domains (ccTLDs). The
of two-letter codes themselves (that may consecutively be used as DNS assignment of two-letter codes themselves (that may consecutively be
top-level domains) is done by ISO TC46/WG2 and are maintained by the used as DNS top-level domains) is done by ISO TC46/WG2 and are
ISO 3166 maintenance agency [ISO.3166.2013]. The selection of the maintained by the ISO 3166 maintenance agency [ISO.3166.2013]. The
operator of a ccTLD is currently governed by [RFC1591], also see selection of the operator of a ccTLD is currently governed by
Section 5.4 Oversight Example 4. [RFC1591], also see Section 5.4.4.
5.1.3. Policy Example 3
IP address allocation and the associated policy development is
distributed too. For instance, the IETF has defined an IPv6 address
range called unicast addresses. For a fraction of that address range
ICANN has been delegated change control (see [RFC3513] section 4 for
details and [GlobAddrPol] for examples). The change control is
further delegated to the Regional Internet Registries (RIRs) which,
guided by policies set by the regional communities, delegate change
control even further e.g., to Local Internet Registries.
5.2. Evaluation Coordination Role Examples 5.2. Evaluation Coordination Role Examples
5.2.1. Evaluation Example 1 5.2.1. IETF Protocol Parameters
As mentioned above, [RFC5226] provides terminology to define common As mentioned above, [RFC5226] provides terminology to define common
policies used by IETF registries associated with IETF protocols. One policies used by IETF registries associated with IETF protocols. One
of the policies that the Policy Role can impose for allocation from a of the policies that the Policy Role can impose for allocation from a
registry is "Expert Review". In this case a subject matter expert registry is "Expert Review". In this case a subject matter expert
will evaluate the allocation request and determine whether an will evaluate the allocation request and determine whether an
allocation will be made. allocation will be made.
An alternative policy for allocation is the requirement for IETF An alternative policy for allocation is the requirement for IETF
Consensus. This is where the IETF has first, in its Policy Consensus. This is where the IETF has first, in its Policy Role,
Development role, set the policy and then, in its Policy Evaluation sets the policy to use its (policy) process to determine consensus
role implements it by determining consensus for a particular registry for a particular registry modification.
modification.
The IANA functions operator (currently operated by ICANN) is the The IANA functions operator (currently operated by ICANN) is the
entity that, for the IETF, coordinates the evaluation of registration entity that, for the IETF, coordinates the evaluation of registration
requests against policies as set by the IETF. requests against policies as set by the IETF.
5.2.2. Evaluation Example 2 5.2.2. Nubmer Resources
IP address allocation policy is developed bottom-up through the IP address allocation policy is developed bottom-up through the
Regional Internet Registry (RIR) communities. The RIR communities Regional Internet Registry (RIR) communities. The RIR communities
perform the Policy Role while at the RIRs the Policy Evaluation Role perform the Policy Role while at the RIRs the Policy Evaluation Role
is performed by IP-Resource Analysts (or similar) that assess is performed by IP-Resource Analysts (or similar) that assess
allocation requests against the policies developed in the Region. allocation requests against the policies developed in the Region.
RIR staff often support or even initiate the policy development RIR staff often support or even initiate the policy development
process. process.
5.2.3. Evaluation Example 3 5.2.3. Domain Names
Generic TLD delegation policy is today developed bottom-up through Generic TLD delegation policy is today developed bottom-up through
ICANN policy processes. As specified in ICANN's bylaws [ADDREF], the ICANN policy processes. As specified in ICANN's bylaws [ADDREF], the
ICANN Board of Trustees (BoT) oversees those process to perform the ICANN Board of Trustees (BoT) oversees those process to perform the
Policy Role. The Policy Evaluation Role is performed under the Policy Role. The Policy Evaluation Role is performed under the
responsibility of the ICANN BoT; staff and various panels evaluate responsibility of the ICANN BoT; staff and various panels evaluate
applications for new generic top-level domains against the policies applications for new generic top-level domains against the policies
developed via the ICANN Policy Development Processes. In addition, developed via the ICANN Policy Development Processes. In addition,
ICANN staff often support these policy development processes. ICANN staff often support these policy development processes.
5.3. Maintenance and Publication of Registry Content 5.3. Maintenance and Publication of Registry Content
5.3.1. IETF Protocol Parameters
5.3.1. Maintenance Example 1
ICANN, as the current IANA functions operator, publishes the protocol ICANN, as the current IANA functions operator, publishes the protocol
parameters registries on the IANA website. Recently the plain-text parameters registries on the IANA website. Recently the plain-text
tables on that website have been augmented with tables in a tables on that website have been augmented with tables in a
structured machine-readable format. The coordination of the structured machine-readable format. The coordination of the
requirements for publication and the implementation of the technical requirements for publication and the implementation of the technical
systems is part of the publication and maintenance responsibility. systems is part of the publication and maintenance responsibility.
5.3.2. Maintenance Example 2 5.3.2. Alternative publication mechanisms
[EDITORIAL NOTE: Add Reverse DNS and WHOIS content as examples of [EDITORIAL NOTE: Add Reverse DNS and WHOIS content as examples of
publication and maintenance] publication and maintenance]
5.4. Oversight Examples 5.4. Oversight Examples
5.4.1. Oversight Example 1 5.4.1. IETF Protocol Parameters
The Internet Architecture Board (IAB) is responsible for overseeing The Internet Architecture Board (IAB) is responsible for overseeing
the process used to create Internet Standards and coordinates with the process used to create Internet Standards and coordinates with
the other entities that have the oversight role for Internet the other entities that have the oversight role for Internet
Registries. Registries.
5.4.2. Oversight Example 2 5.4.2. Nubmer Resources
Collectively, the communities served by the Regional Internet Collectively, the communities served by the Regional Internet
Registries oversee the policy development for global Internet address Registries oversee the policy development for global Internet address
allocation policies. allocation policies.
5.4.3. Oversight Example 3 5.4.3. Coordination - gTLDs vs special domain names
Collectively, the stakeholders involved in the ICANN policy Collectively, the stakeholders involved in the ICANN policy
development processes serve to oversee the policy development for development processes serve to oversee the policy development for
generic TLD allocation processes. generic TLD allocation processes.
Other examples of coordination around IETF protocols are coordination Other examples of oversight around IETF protocols include the
with the ITU-T when the ENUM protocol started to use E.164 coordination between the IAB and the ITU-T when the ENUM protocol
identifiers (telephone numbers)[RFC3245]. Another example is the started to use E.164 identifiers (telephone numbers)[RFC3245].
coordination between the IETF protocol development process and Another example is the facilitation of coordination between the IETF
reservations of labels at the top-level of the domain name space with protocol development process and reservations of labels at the top-
RFC6761 as a recent example. level of the domain name space with RFC6761 as a recent example.
5.4.4. Oversight Example 4 5.4.4. Coordination - ccTLD Administration
The astute reader might have noticed that in Policy Example 2 in Some readers might have noticed that in the Policy Example in
Section 5.1 the policy by which ccTLD operators are selected refers Section 5.1.3 the policy by which ccTLD operators are selected refers
to RFC1591. RFC1591 was published in the time that the IANA to RFC1591. RFC1591 was specified and published by the IANA, while
functions were executed under the responsibility of Jon Postel and Internet was still an ARPA project and before ICANN and the IETF
before institutions like ICANN and the IETF existed and the IAB had a existed. The IAB at the time maintained loose oversight of IANA but
different set of responsibilities. Should an update of RFC1591 or a had a different set of responsibilities. Should an update of RFC1591
declaration of the historic nature of that document be needed then or a declaration of the historic nature of that document be needed
such action would most likely involve stewardship and coordination by then such action would most likely involve stewardship and
the IAB and ICANN. coordination by the IAB and ICANN.
6. Security Considerations 6. Security Considerations
As discussed in Section Section 1.1 Internet Registries and the model As discussed in Section Section 1.1 Internet Registries and the model
discussed in this document are critical to elements of Internet discussed in this document are critical to elements of Internet
security. However, this document simply discusses that model rather security. However, this document simply discusses that model rather
than changing it and consequently does not directly affect the than changing it and consequently does not directly affect the
security of the Internet. security of the Internet.
7. Contributors and Acknowledgemetns 7. Contributors and Acknowledgemetns
This text has been [is being] developed within the IAB IANA strategy This text has been [is being] developed within the IAB IANA evolution
program. The ideas and many, if not most, text fragments, and program. The ideas and many, if not most, text fragments, and
corrections came from or were inspired on comments from: Jaap, corrections came from or were inspired on comments from: Bernard
Akkerhuis, Jari Arkko, Marcelo Bagnulo, Mark Blanchet, Brian Aboba, Jaap Akkerhuis, Jari Arkko, Marcelo Bagnulo, Mark Blanchet,
Carpenter, David Conrad, John Curran, Leslie Daigle, Elise Gerich, Brian Carpenter, David Conrad, Steve Crocker, John Curran, Alissa
Russ Housley, John Klensin, Danny McPherson, Thomas Narten, Andrei Cooper, Leslie Daigle, Elise Gerich, Russ Housley, John Klensin,
Robachevsky, and Greg Wood. Further inspiration and input was drawn Bertrand de La Chapelle, Danny McPherson, George Michaelson, Thomas
from various meetings with IETF and other Internet community (RIRs, Narten, Andrei Robachevsky, and Greg Wood. Further inspiration and
ISOC, W3C, IETF & IAB) leadership. input was drawn from various meetings with IETF and other Internet
community (RIRs, ISOC, W3C, IETF & IAB) leadership.
It should not be assumed that those acknowledged endorse the text.
8. IANA Considderations 8. IANA Considderations
This memo does not contain any specific instruction to any entity in This memo does not contain any specific instruction to any entity in
the Implementer Role. the Implementer Role.
9. References 9. Informative References
[BCP10] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, [BCP10] Galvin, J., Ed., "IAB and IESG Selection, Confirmation,
and Recall Process: Operation of the Nominating and Recall and Recall Process: Operation of the Nominating and Recall
Committees", BCP 10, RFC 3777, June 2004. Committees", BCP 10, RFC 3777, June 2004.
Dawkins, S., "Nominating Committee Process: Earlier Dawkins, S., "Nominating Committee Process: Earlier
Announcement of Open Positions and Solicitation of Announcement of Open Positions and Solicitation of
Volunteers", BCP 10, RFC 5633, August 2009. Volunteers", BCP 10, RFC 5633, August 2009.
[GlobAddrPol] [GlobAddrPol]
"Board's Review Procedures for Global Internet Number "Board's Review Procedures for Global Internet Number
Resource Policies Forwarded for Ratification by the ASO Resource Policies Forwarded for Ratification by the ASO
Address Council in Accordance with the ASO MoU", July Address Council in Accordance with the ASO MoU", July
2005. 2005.
[ISO.3166.2013] [ISO.3166.2013]
International Organization for Standardization, "Codes for International Organization for Standardization, "Codes for
the representation of names of countries and their the representation of names of countries and their
subdivisions ", ISO Standard 3166, November 2013. subdivisions, 3rd edition", ISO Standard 3166, November
2013.
[RFC1591] Postel, J., "Domain Name System Structure and Delegation", [RFC1591] Postel, J., "Domain Name System Structure and Delegation",
RFC 1591, March 1994. RFC 1591, March 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2850] Internet Architecture Board, and B. Carpenter, "Charter [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of
of the Internet Architecture Board (IAB)", BCP 39, RFC the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
2850, May 2000. May 2000.
[RFC2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860, June 2000. Internet Assigned Numbers Authority", RFC 2860, June 2000.
[RFC3245] Klensin, J.IAB, "The History and Context of Telephone [RFC3245] Klensin, J. and IAB, "The History and Context of Telephone
Number Mapping (ENUM) Operational Decisions: Informational Number Mapping (ENUM) Operational Decisions: Informational
Documents Contributed to ITU-T Study Group 2 (SG2)", RFC Documents Contributed to ITU-T Study Group 2 (SG2)", RFC
3245, March 2002. 3245, March 2002.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003. (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF [RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF
Administrative Support Activity (IASA)", BCP 101, RFC Administrative Support Activity (IASA)", BCP 101, RFC
4071, April 2005. 4071, April 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, [RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G., and
G.Internet Architecture Board, "Defining the Role and Internet Architecture Board, "Defining the Role and
Function of IETF Protocol Parameter Registry Operators", Function of IETF Protocol Parameter Registry Operators",
RFC 6220, April 2011. RFC 6220, April 2011.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, February 2013. RFC 6761, February 2013.
[RFC7020] Housley, R., Curran, J., Huston, G. and D. Conrad, "The [RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The
Internet Numbers Registry System", RFC 7020, August 2013. Internet Numbers Registry System", RFC 7020, August 2013.
Appendix A. Document Editing Details Appendix A. Document Editing Details
[Text between square brackets starting with initials are editor [Text between square brackets starting with initials are editor
notes. Any other text between square brackets assumes an action by notes. Any other text between square brackets assumes an action by
the RFC editor prior to publication as an RFC. In most cases this the RFC editor prior to publication as an RFC. In most cases this
will be removal, sometimes a stylistic or editorial choices ore will be removal, sometimes a stylistic or editorial choices ore
question is indicated] [This section and its subsections should be question is indicated] [This section and its subsections should be
removed at publication as RFC] removed at publication as RFC]
Appendix A.1. Version Information A.1. Version Information
Appendix A.1.1. draft-kolkman-iana-framework-00
This draft is the result of a set of brainstorms in the IAB IANA
program, it does not claim to reflect any consensus.
Appendix A.1.2. draft-kolkman-iana-framework-00 -> draft-iab-iana-
framework-00
Added section "On Accountability" and "On Delegation". A.1.1. draft-iab-iana-framework-01 -> draft-iab-iana-framework-02
Refined some of the phrasing based on a thorough review by David Reordered paragraphs in the Discussion to align them with the
Conrad" order in the Key Principles. Also changed the order because
Accountability mechanisms may depend on the kinds of separation
and delegation applied.
Added a reference to [RFC7020] in Section 1.3 and clarified the Renamed the section titles for the examples from numbers to more
informative rather than normative nature of the examples. descriptive titles.
Added section Section 3 and changed the name of section Section 4. Significant rewording to improve readability based on feedback by
Alissa Cooper.
Nits and minor edits. Added the paragraph talking about general use in Section 1.2 based
on feedback from John Curran.
Appendix A.1.3. draft-iab-iana-framework-00 -> draft-iab-iana- A.1.2. draft-iab-iana-framework-00 -> draft-iab-iana-framework-01
framework-01
Significantly reordered the document by pulling the examples out Significantly reordered the document by pulling the examples out
of the descriptions of the roles and moving those to section of the descriptions of the roles and moving those to section
Section 5. Section 5.
Split the "Implementation Role" into two different roles Split the "Implementation Role" into two different roles
explicitly: Evaluation and Maintenance. Both those roles can be explicitly: Evaluation and Maintenance. Both those roles can be
headed under Implementation aspects. headed under Implementation aspects.
Refined text about te "what, who and why" and gave an overview in Refined text about te "what, who and why" and gave an overview in
section Section 1.2 section Section 1.2
Reworded the text in Section 4.3 to highlight that only the name Reworded the text in Section 4.2 to highlight that only the name
assignment is the policy aspect that has been delegated. assignment is the policy aspect that has been delegated.
Similarly, in section Section 5.1 I tried to illustrate that even Similarly, in section Section 5.1 I tried to illustrate that even
within the domain name assignment in the root there are delegated within the domain name assignment in the root there are delegated
policies by introducing the ISO3166 reference. policies by introducing the ISO3166 reference.
Added Oversight Example 4 in Section 5.4 as an example of policy Added Oversight Example 4 in Section 5.4 as an example of policy
that exists for over a few decades and for which an update would that exists for over a few decades and for which an update would
need coordination need coordination
Nits and minor edits. Nits and minor edits.
Appendix A.1.4. TODO A.1.3. draft-kolkman-iana-framework-00 -> draft-iab-iana-framework-00
o Possibly add a terminology section with terms like maintenance, Added section "On Accountability" and "On Delegation".
coordination, etc further explained.
Refined some of the phrasing based on a thorough review by David
Conrad"
Added a reference to [RFC7020] in Section 1.3 and clarified the
informative rather than normative nature of the examples.
Added section Section 3 and changed the name of section Section 4.
Nits and minor edits.
A.1.4. draft-kolkman-iana-framework-00
This draft is the result of a set of brainstorms in the IAB IANA
program, it does not claim to reflect any consensus.
A.1.5. TODO
o [RFC EDITOR: BCP10 reference [BCP10] needs to be formatted o [RFC EDITOR: BCP10 reference [BCP10] needs to be formatted
correctly. The annotation hack used to list multiple RFCs that correctly. The annotation hack used to list multiple RFCs that
make up BCP10 does not seem to work.] make up BCP10 does not seem to work.]
o Review and potentially add clarifying text on the use of 'Internet A.2. Subversion information
Registries' (IP and AS numbers, Domain Names, and IETF Protocol
registries).
Appendix A.2. Subversion information
$Id: iana-framework.xml 30 2014-01-22 11:42:00Z olaf $ $Id: iana-framework.xml 32 2014-03-19 11:17:02Z olaf $
Authors' Addresses Authors' Addresses
Internet Architecture Board Internet Architecture Board
Email: iab@iab.org EMail: iab@iab.org
Olaf Kolkman (editor)
Olaf Kolkman, editor
Stichting NLnet Labs Stichting NLnet Labs
Science Park 400 Science Park 400
Amsterdam, 1098 XH Amsterdam 1098 XH
The Netherlands The Netherlands
Email: olaf@nlnetlabs.nl EMail: olaf@nlnetlabs.nl
URI: http://www.nlnetlabs.nl/ URI: http://www.nlnetlabs.nl/
 End of changes. 89 change blocks. 
387 lines changed or deleted 422 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/