(*) Comments submitted after the posted Close Date/Time are not guaranteed to be considered in any final summary, analysis, reporting, or decision-making that takes place once this period lapses.

FINAL VERSION TO BE SUBMITTED IF RATIFIED

Please click here to download the PDF below.

FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC

A central part of the IANA contract is for a single organization to fulfill the following responsibilities:

• Maintain unbiased, fair, and open registries for protocol numbers as requested in the Request for Comments defined by the Internet Engineering Task Force;
• Manage the allocation of limited global resources for the operation of the Internet itself, based on verified actual needs only. This management includes Internet Protocol addresses and Autonomous System Numbers;
• Maintain the contract registry for Top Level Domains containing the contracts or Memorandums of Understanding between each registry and ICANN for ccTLDs and gTLDs. This responsibility also includes the management of the database for the delegation of data, specifically including Glue Records, Name Servers and DNSSEC keys;
• Operate a free, open, unrestricted, and central WHOIS service (currently found at whois.iana.org) for all globally defined allocations and delegations (domain names, IP addresses, and ASNs). This service should return the contractual details of each allocation or delegation, as well as the addresses of the WHOIS services to obtain further details;
• Operate and maintain a registry for special purpose domain names such as .arpa; and
• Ensure that the Internet works as a neutral transportation platform and that all end-points are able to access each other in a non-discriminating way.

Based on these responsibilities, the central administration of global resources must be operated by a non-political, non-commercial, and non-policy-making single-purpose entity. As such, it is best that IANA be charged with this task.

In order to obtain a mandate for such an organization, the responsibilities to be completed and managed by IANA should be as clearly defined, transparent, and documented as possible. Each contract, delegation, allocation, and definition must be openly listed and easily accessible.

For the end-user requesting any resource, the IANA website should contain clear documentation of how resources can be obtained. As IANA is usually not the institution to assign the resource allocation, it should point end-users to the party that is responsible for processing the requests. IANA should also provide a summary of each request process.

For the sake of transparency, IANA should provide an open and easily accessible interface that follows the thin-WHOIS approach of whois.iana.org. Each interested user must be able to understand why a resource is allocated to a registry and where the information can be found using the next level of WHOIS downstream. IANA may provide a recursive, multi-lingual web-interface resolving the deeper levels of WHOIS and provide an all-in-one access to the final end-user data that resources are assigned to. Of course this interface has to respect local laws where the data is retrieved.

The ALAC would also like to note the following four points: 

1. The current documentation of responsibilities makes it difficult for a typical end-user to find the official path from the IANA webpage to the party (LIR, registrar, reseller, etc.) responsible for processing a request. The current webpage of IANA needs to become much clearer on the hierarchy of allocations and sub-assignments. This change should also cover the resource allocation pages, including abstracts of the downstream registration process and the retrieval of existing assignments (i.e. Thin Whois).
2. Each registry operated by IANA is currently purely technical. Given the context of the registry in question, the current documentation is usually sufficient. Unfortunately the technical background differs in historical and operational aspects, various word changes, and the requesting methods given the current policy or RFC that defines the registry. Without a solid knowledge of this very special issue, the requested resource is irrelevant; as of now, the IANA pages are confusing up to a point of being a distraction. This problem cannot be solved in a simple way, each of those registries are different and the applicable rules change over time. As a result, it is hard to provide a consistent presentation of such a variety of resources. Nevertheless, it should be undertaken.
3. There should be a documented way, viewable on the IANA webpage, of how an end-user can change the parties in the allocation hierarchy of the end-users Internet resource. How else can an end-user know how to change the LIR or RIR of his address space (i.e. after a relocation to a different country)? How else can an end-user change a reseller or registrar for a domain name? What happens if an intermediate party ceases to exist? What happens if an intermediate party wants to change the uptree party if the LIR changes the RIR, the reseller changes the registrar, the reseller changes the registry, etc.? How is the end-user involved?
4. The IANA web page should be easily accessible for people with disabilities. Plain HTML, a good choice of CSS, and only some scripting for comfort features should be implemented in this regard.

FIRST DRAFT SUBMITTED

Central part of the IANA contract is to provide responsibility for the following by a single organization:

• Maintain unbiased, fair, and open registries for protocol numbers as requested in the RFCs as defined by the IETF.
• Manage allocations of limited global resources for the operation of the Internet itself based verified actual needs only. This includes Internet Protocol addresses and Autonomous System Numbers.
• Maintain the contract registry for Top Level Domains containing the contracts or MoU between each registry and ICANN for ccTLDs and gTLDs. Manage the database for delegation data especially including glue Name Servers and DNSSEC keys.
• Operate a free, open, unrestricted, and central WHOIS service (currently know as whois.iana.org) for all globally defined allocations and delegations (domain names, IP addresses, and ASNs). This services should return the contractual details of each allocation or delegation as well as the address of the WHOIS services to obtain further details.
• Operate and maintain a registry for special purpose domain names like *.ARPA.

The Internet can only work as an neutral transportation platform, if all end-points can access each other in a non-discriminating way. Therefore the central administration of global resources needs to be operated by a non-political, non-commercial, and non-policy-making single-purpose entity: IANA.

In order to get acceptance for such an organization, the activities should be as clearly defined, transparent, and documented as possible. Each contract, each delegation, allocation, or definition needs to be openly listed and easily accessible of the full sources, resulting in this action.

For the end-user requesting any resource, the IANA website should contain a clear documentation, how the ressource can be obtained. Because IANA is usually not the institutiuon to make the ressouce allocation, it should point the end-user to the party which responsible for processing the request. Nevertheless IANA should provide a major abstract of each requesting process. A few lines are sufficient and should be provided by the sub-registry IANA is delegation to.

For sake of transparency, IANA should provide an open and easy to access interface to following the thin-WHOIS approach of whois.iana.org. Each interested user must be able to understand, why a ressouce is allocated to which registry and where the information can be found using the next level of WHOIS downstream. IANA may provide a recursive, multi-lingual web-interface resolving the deeper levels of WHOIS and provide a all-in-one access to the final end-user data the ressouce is assigned to. Of course this interface has to respect the local laws, where the data was retrieved from.