]>

iab@iab.org

Stichting NLnet Labs

Science Park 400 1098 XH Amsterdam The Netherlands olaf@nlnetlabs.nl http://www.nlnetlabs.nl/

General Internet Architecture Board(IAB) IANA Governance This document provides a framework for describing the management of Internet registries managed by the Internet Assigned Numbers Authority. It defines terminology describing the various roles and responsibilities associated with management of Internet registry functions. [ 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 ]

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. They are needed to record the definitive value and meaning of identifiers that protocols use when communicating with each other. Management of Internet registries must be done in a predictable, stable and secure manner in order to ensure that protocol identifiers have consistent meanings and interpretations across all implementations and deployments. Protocol identifier values can be numbers, strings, addresses, and so on. They are uniquely assigned for one particular purpose or use. They can be maintained in centrally maintained lists (such as, for instance, lists of cryptographic algorithms in use in a particular protocol) or hierarchically allocated and assigned by separate entities at different points in the hierarchy (such as for IP addresses and domain names). At the time of writing, the Internet Assigned Numbers Authority (IANA) maintains over one thousand protocol parameter registries. Stable and predictable assignment and registration of protocol identifiers for Internet protocols is of great importance to many stakeholders, including developers, vendors, and customers, as well as users of devices, software, and services on the Internet. These stakeholders use and depend on registries and implicitly trust the registry system to be stable and predictable. The registry system is built on trust and mutual cooperation; the use of the registries is voluntary and is not enforced by mandates or certification policies. Stability and consistency of Internet registries is achieved through the definition of appropriate and clear policies for making additions to or updating existing entries. Such policies must take into account the technical and operational properties of the technology that makes use of the registries. At the same time, it must be possible to evolve the systems and policies for managing registry contents as the Internet itself evolves.

The Internet Engineering Task Force (IETF) and its predecessors have traditionally separated the publication mechanism of its protocol specifications, published in immutable RFCs, from the registries containing protocol parameters. The latter is maintained by a set of functions traditionally known collectively as the Internet Assigned Numbers Authority (IANA). Dating back to the somewhat before the earliest days of the Internet, the specification publication function and the registry maintenance functions were tightly coupled: Jon Postel of the Information Sciences Institute (ISI) of the University of Southern California (USC) was responsible for both the RFC publications and the IANA function. However, this tight coupling was never a requirement and indeed, today the RFC Editor and IANA function are contracted to different entities. (The RFC publication process and the IANA protocol parameter policy development process and oversight remain closely coupled. For instance,one of the responsibilities of the IAB is oversight over the RFC Series and IANA ) One way to approach Internet Registry Management is to examine the what, why, who and how. The Internet or IANA Registries are tables with assignments and allocations of values (the What), established by explicit directions contained within Request for Comment (RFC) documents (the Why). The framework herein applies to individual registries. However Internet registries are colloquially grouped into 3 classes: Names, Numbers, and IETF Protocol Parameters. The framework applies, with some nuance, to all registries, regardless of their class. In this framework we identify major 4 roles: The Policy, The Oversight, the Evaluation Coordination, and Maintenance and Publication Roles (the latter two are both both implementation aspects). The entities in those roles can be interpreted as 'the who' while their collective responsibilities determine 'the how'. Normally we use the term IANA for the set of functions with specific responsibilities within the context of Internet Registries (mainly those under Implementation Aspects 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, the maintenance, implementation and publication of most of the IETF protocol Registries is performed by the Internet Corporation for Assigned Names and Numbers (ICANN).

This document provides a framework for describing the management of Internet Registries as they are currently implemented. It defines terminology describing the various roles and responsibilities associated with those roles in . In we enumerate a few key principles for the implementation of the Framework. In we discuss some of the issues that came up during the development of the draft. Finally, in we provide a number of examples on how the framework applies today. Those sections intend to demonstrate that the framework can be applied to the situation today, albeit with the necessary nuance, and that it is a helpful concept going forward. Although this document can be read independent of and -- which document the requirements specific to a subset of all current IANA function Internet registries, namely the IETF protocol parameter registries and the Internet Numbers Registry System respectively --, those RFCs provide context and example of the subject matter of this document. The words must, should, shall, required, may and such should not be interpreted as normative language as defined in , but in their plain English meaning.

In this section we discuss the roles relevant to Internet Registries in terms of an abstract registry that is defined as part of a arbitrary technical specification. Registry management involves 3 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.

Description: Registries may need to have additional values added, or an existing entry may need to be removed, clarified, or updated in some manner. The policy development role creates the registry and defines the policies that describes who can make updates or additions, what sort of review (if any) is needed, the conditions under which update requests would normally be granted or when they might not, the security requirements of these interactions, etc. The entity performing this role may delegate its policy responsibilities for part or all of the parameters within the registry. Concequently, in this document the word "policy" is used to refer to a specific course or principle of action for administration of a technical resource maintained within specific registries" Key Responsibilities: The policy development role refers to the creation of the governing policies that define how and when a registry can be updated or modified. Primary Output: A set of policies by which registries can be populated.

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.

Evaluation Role for short. Key Responsibility: Coordinate, operate, and process the timely evaluation of registration requests based on policies set by the Policy Role. Primary Output: A smoothly functioning system in which requests for registry updates are submitted and are evaluated and processed in a manner consistent with the policy guidance with the results recorded and published as appropriate. In some cases, the evaluation of requests is a straightforward task requiring little subjective evaluation, whereas in other cases evaluation is more complex and requires subject matter experts as defined by the relevant policy guidance. Relation to other roles and activities: The output of the evaluations is input to the process of assignment, delegation, and/or population of the registries as performed by the entity in the Maintenance Role (). The evaluations are performed based on the policies as defined by the Policy role. The coordination of the evaluation is different from the evaluation of a request itself: The Evaluation Role handles the request for allocation or maintenance of a record and may, under guidance of and in coordination with the policy role, delegate the actual evaluation to a third party.

Maintenance Role for short. Key Responsibility: The maintenance of the registries content: allocating or assigning parameters after positive evaluation and based on established policies, keeping appropriate record of transactions, and making the registries publicly available. Primary Output: Easy and convenient access to registry contents, with additions and updates appearing in a timely manner. Note: Registry maintenance and publication are strictly mechanical functions. In practice the entity that performs those functions will often perform some or all of the responsibilities of the Policy Evaluation Coordination. For instance, verification that an application/registration request is correct is a Policy Evaluation responsibility that can reasonably be explicitly assigned to the entity performing the IANA function by the entity that performs the Policy Development Role.

Description: The oversight role refers to a high-level responsibility for ensuring that the other two roles are operating satisfactorily, stepping in if significant changes are needed in the policies or implementation of a registry. Key Responsibility: Ensure that policies and the implementation of registries are aligned in a way that supports the coherent long-term development and use of shared Internet resources. Coordinate with entities with similar roles for other registries. The oversight role is normally isolated with respect to the actual policy development. That said, it may serve to resolve appeals or ratify developed policies.

Any IANA framework should be implementable with the following key principles in mind. Stable and Predictable implementation of the Internet Registries Function is important for establishing global trust. Oversight, implementation, and policy development roles are accountable to the materially 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. The oversight, policy development, and implementation roles should be separate or separable. A clear distinction between the roles enhances the transparency and makes it clearer who is accountable to who. It should be possible to delegate any of the roles (policy, implementation, or oversight) for registries or parts thereof.

For many registries there is a de-facto separation of the Policy Development and the Evaluation coordination that takes place at implementation. While this has never been an explicit requirement, it seems that splitting those roles can surface a lack of clarity in the policies. In addition, having the policy setting, oversight and evaluation roles separated prevents the evaluation role from being burdened 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 (also see ). In addition the IAOC, a body responsible for IETF administrational and financial matters, 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 .

Most, if not all, protocol parameter registries were created by the IETF or its predecessors. Today, most IETF protocols registries are maintained by the IANA at ICANN. However, nothing in this framework prohibits the delegation of the oversight, policy, evaluation, or maintenance role (or any combination of these) of specific protocol parameter registries to other organizations. In some circumstances, that may be desirable and allow improved registry management for the good of the global Internet community. Delegation of an IANA registry may be desirable for several reasons, including support for more inclusive registry policy development, distributing registry operations globally, and accommodating public policy considerations in registry management. While delegation of an IANA registry in these situations can improve the registry service 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 for successful IANA registry delegation. Such guidelines are out of scope for this document. Examples for registries where the responsibility for developing policy has been delegated in whole or in part include the assignment of domain names and the assignment of Internet Protocol (IP) address blocks (both considered policy issues by ), and the autonomous system (AS) number registry . demonstrates that that delegation can be very specifically bounded: "Note that (a) assignments of domain names for technical uses (such as domain names for inverse DNS lookup), (b) assignments of specialised address blocks (such as multicast or anycast blocks), and (c) experimental assignments are not considered to be policy issues [...]". These special-purpose names and addresses are assigned in the same manner as protocol parameters except that coordination is needed during policy setting and actual assignment of the values. The oversight bodies may facilitate the coordination. Also see Policy Examples 2 and 3 in .

As with the IETF and the corresponding IANA Protocol registries, other standards bodies (and other institutions) have long histories of defining and creating registries and the parameters, tables, and other values that make them up. Those normal practices may obviously extend to registries and their contents for use on the Internet. 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 Parameter registries as described in . The IETF also has the authority to create registries that pertain to the Domain Name System, but only for specify technical use . Finally the IETF has the (exclusive) authority to make technical assignment for Number Resources out of the currently reserved address space ( and ).

The authors are aware that this framework uses less, slightly different, and more generic terms to describe the various roles than . is a document that specifically pertains to the IETF protocol parameter registries. For instance, 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 above. 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'.

Not coincidentally, the following 3 examples map to how the IANA registration functions are currently organized: IETF Protocol Parameter Registries, Number Resources and Domain Names.

The IETF, through the IESG (see section 2.3), acts in this role when in the "IANA Considerations" sections of its RFCs it specifies the creation of a new registry, specifies initial entries, and specifies a policy for adding additional entries to the registry in the future. provides guidance and terminology that has proven useful within the IETF for describing common policies for managing its registries. Those terms include "Private Use", "Hierarchical allocation", "First Come First Served", "Expert Review", "Specification Required", "IESG Approval", "IETF Consensus", and "Standards Action". The IETF uses these and, if needed, other templates to define the policy through which registries are populated.

The Domain Name System (DNS) protocol allows for hierarchical maintenance of the domain name registries, and publication thereof. ICANN is currently responsible for change control at the root zone which includes setting and maintaining policies for that zone. Change control, policy control, and publication authority follows the DNS hierarchy; although ICANN is the authoritative entity in the policy role for the root zone, it is not authoritative for all domains below the root. For example the IETF sets the policy for determining which names are allocated in the ietf.org zone. For country code top-level domains (ccTLD) the policies are set by the ccTLD registry in coordination with local community, local regulator(s), and/or other national bodies. Even the policy for assignment of names within the root is subject nuance. For instance, ICANN has reserved two letter top-level domains for the use as country and territory code Top Level Domains (ccTLDs). The assignment of two-letter codes themselves (that may consecutively be used as DNS top-level domains) is done by ISO TC46/WG2 and are maintained by the ISO 3166 maintenance agency . The selection of the operator of a ccTLD is currently governed by , also see Oversight Example 4.

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 section 4 for details and 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.

As mentioned above, provides terminology to define common policies used by IETF registries associated with IETF protocols. One of the policies that the Policy Role can impose for allocation from a registry is "Expert Review". In this case a subject matter expert will evaluate the allocation request and determine whether an allocation will be made. An alternative policy for allocation is the requirement for IETF Consensus. This is where the IETF has first, in its Policy Development role, set the policy and then, in its Policy Evaluation role implements it by determining consensus for a particular registry modification. The IANA functions operator (currently operated by ICANN) is the entity that, for the IETF, coordinates the evaluation of registration requests against policies as set by the IETF.

IP address allocation policy is developed bottom-up through the Regional Internet Registry (RIR) communities. The RIR communities perform the Policy Role while at the RIRs the Policy Evaluation Role is performed by IP-Resource Analysts (or similar) that assess allocation requests against the policies developed in the Region. RIR staff often support or even initiate the policy development process.

Generic TLD delegation policy is today developed bottom-up through ICANN policy processes. As specified in ICANN's bylaws [ADDREF], the ICANN Board of Trustees (BoT) oversees those process to perform the Policy Role. The Policy Evaluation Role is performed under the responsibility of the ICANN BoT; staff and various panels evaluate applications for new generic top-level domains against the policies developed via the ICANN Policy Development Processes. In addition, ICANN staff often support these policy development processes.

ICANN, as the current IANA functions operator, publishes the protocol parameters registries on the IANA website. Recently the plain-text tables on that website have been augmented with tables in a structured machine-readable format. The coordination of the requirements for publication and the implementation of the technical systems is part of the publication and maintenance responsibility.

[EDITORIAL NOTE: Add Reverse DNS and WHOIS content as examples of publication and maintenance]

The Internet Architecture Board (IAB) is responsible for overseeing the process used to create Internet Standards and coordinates with the other entities that have the oversight role for Internet Registries.

Collectively, the communities served by the Regional Internet Registries oversee the policy development for global Internet address allocation policies.

Collectively, the stakeholders involved in the ICANN policy development processes serve to oversee the policy development for generic TLD allocation processes. Other examples of coordination around IETF protocols are coordination with the ITU-T when the ENUM protocol started to use E.164 identifiers (telephone numbers). Another example is the coordination between the IETF protocol development process and reservations of labels at the top-level of the domain name space with RFC6761 as a recent example.

The astute reader might have noticed that in Policy Example 2 in the policy by which ccTLD operators are selected refers to RFC1591. RFC1591 was published in the time that the IANA functions were executed under the responsibility of Jon Postel and before institutions like ICANN and the IETF existed and the IAB had a different set of responsibilities. Should an update of RFC1591 or a declaration of the historic nature of that document be needed then such action would most likely involve stewardship and coordination by the IAB and ICANN.

As discussed in Section Internet Registries and the model discussed in this document are critical to elements of Internet security. However, this document simply discusses that model rather than changing it and consequently does not directly affect the security of the Internet.

This text has been [is being] developed within the IAB IANA strategy program. The ideas and many, if not most, text fragments, and corrections came from or were inspired on comments from: Jaap, Akkerhuis, Jari Arkko, Marcelo Bagnulo, Mark Blanchet, Brian Carpenter, David Conrad, John Curran, Leslie Daigle, Elise Gerich, Russ Housley, John Klensin, Danny McPherson, Thomas Narten, Andrei Robachevsky, and Greg Wood. Further inspiration and input was drawn from various meetings with IETF and other Internet community (RIRs, ISOC, W3C, IETF & IAB) leadership.

This memo does not contain any specific instruction to any entity in the Implementer Role.

Dawkins, S., "Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers", BCP 10, RFC 5633, August 2009. Dawkins, S., "The Nominating Committee Process: Open Disclosure of Willing Nominees", BCP 10, RFC 5680, October 2009. Leiba, B., "Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership", BCP 10, RFC 6859, January 2013. USC/Information Sciences Institute

4676 Admiralty WayMarina del ReyCA90292US+1 310 822 1511+1 310 823 6714Postel@ISI.EDU

Harvard University

1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu

GeneralkeywordIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. Internet Architecture BoardThis memo documents the composition, selection, roles, and organization of the Internet Architecture Board. It replaces RFC 1601. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document places on record the text of the Memorandum of Understanding concerning the technical work of the IANA that was signed on March 1, 2000 between the IETF and ICANN, and ratified by the ICANN Board on March 10, 2000. This memo provides information for the Internet community. IABRFC 2916 assigned responsibility for a number of administrative and operational details of Telephone Number Mapping (ENUM) to the IAB. It also anticipated that ITU would take responsibility for determining the legitimacy and appropriateness of applicants for delegation of "country code"-level subdomains of the top-level ENUM domain. Recently, three memos have been prepared for the ITU-T Study Group 2 (SG2) to explain the background of, and reasoning for, the relevant decisions. The IAB has also supplied a set of procedural instructions to the RIPE NCC for implementation of their part of the model. The content of the three memos is provided in this document for the information of the IETF community. This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. [STANDARDS-TRACK] This document describes the structure of the IETF Administrative Support Activity (IASA) as an activity housed within the Internet Society (ISOC). It defines the roles and responsibilities of the IETF Administrative Oversight Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IAOC. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.</t><t> This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t> In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t> This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Internet Architecture BoardMany Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names. This document provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers.</t><t> This document also provides information about the processes for further evolution of the Internet Numbers Registry System.</t><t> This document replaces RFC 2050.</t><t> This document does not propose any changes to the current Internet Numbers Registry System. Rather, it documents the Internet Numbers Registry System as it works today. . International Organization for Standardization

[Text between square brackets starting with initials are editor notes. Any other text between square brackets assumes an action by the RFC editor prior to publication as an RFC. In most cases this will be removal, sometimes a stylistic or editorial choices ore question is indicated] [This section and its subsections should be removed at publication as RFC]

This draft is the result of a set of brainstorms in the IAB IANA program, it does not claim to reflect any consensus.

Added section "On Accountability" and "On Delegation". Refined some of the phrasing based on a thorough review by David Conrad" Added a reference to in and clarified the informative rather than normative nature of the examples. Added section and changed the name of section . Nits and minor edits.

Significantly reordered the document by pulling the examples out of the descriptions of the roles and moving those to section . Split the "Implementation Role" into two different roles explicitly: Evaluation and Maintenance. Both those roles can be headed under Implementation aspects. Refined text about te "what, who and why" and gave an overview in section Reworded the text in to highlight that only the name assignment is the policy aspect that has been delegated. Similarly, in section I tried to illustrate that even within the domain name assignment in the root there are delegated policies by introducing the ISO3166 reference. Added Oversight Example 4 in as an example of policy that exists for over a few decades and for which an update would need coordination Nits and minor edits.

Possibly add a terminology section with terms like maintenance, coordination, etc further explained. [RFC EDITOR: BCP10 reference needs to be formatted correctly. The annotation hack used to list multiple RFCs that make up BCP10 does not seem to work.] Review and potentially add clarifying text on the use of 'Internet Registries' (IP and AS numbers, Domain Names, and IETF Protocol registries).

$Id: iana-framework.xml 30 2014-01-22 11:42:00Z olaf $