Page History

...

FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC

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

• Maintain unbiased, fair, and open registries for protocol numbers as requested in the RFCs as defined by the IETF.
• Manage allocations of limited global ressources for the operation of the Internet ifself based verified actual needs only. This includes Internet Protocol addresses and Autonoumus 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.

The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.

FIRST DRAFT SUBMITTED

• 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 adresses, 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 plattform, if all end-points can access each other in a non-discriminating way. Therefore the central administration of global ressources 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 organisation, 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 accessable of the full sources, resulting in this action.

For the end-user requesting any ressouce, 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.

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

1. The current documentation makes it hard for a typical end user to find the canonical way from the IANA webpage down to the party (LIR, registrar, reseller) responsible to process his request. The current web page of IANA needs to become much clearer on the hierarchy of allocations and (sub)-assignments. This need cover the ressouce allocation pages (include abstracts of the downstream registration process) as well as the retrieval of existing assignments (thin Whois).
2. Each registry operated by IANA is currently pure technical. Given the context of the registry in question, the current documentaion is usually sufficient. Unfortunly the technical background differ in historical and operational aspects, wordings change over time, requesting methods depend on the current policy or RFC defining the registy. Without a solid knowledge in this very sepecial issue, the requested ressouce is relevant, the IANA pages are confusing up to distracting. This problem can't be solved in a simple way, each of those registries are different and the rules changes over time. It's hard to provide a consistent presentation of such a varity of ressouces, but it should be tried.
3. There should be a documented way (seen on the IANA webpage) how a end user can change the parties in the allocation hierarchy of his internet ressouce. How can an end user change the LIR or RIR of his address space (i.e. after a relocation to a different country)? How can an end user change his reseller or registrar for his domain name? What happens if an intermediate party chease to exist? What happens of an intermediate party want to change the uptree party (LIR changes the RIR, reseller changes the registrar, reseller changes the (com-)registry)? How is the end user involved?
4. The IANA web page should be easly accessible even for people with disablities. Plain HTML, a good choice of CSS, and only some scripting for comfort features should be the way to go.

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.

 The first draft submitted will be placed here before the call for comments begins.