5. Can process improvements or performance enhancements be made to the IANA functions contract to better reflect the needs of users of the IANA functions to improve the overall customer experience? Should mechanisms be employed to provide formalized user input and/or feedback,outreach and coordination with the users of the IANA functions? Is additional information related to the performance and administration of the IANA functions needed in the interest of more transparency? Please provide specific information as to why or why not. If yes, please provide specific suggestions.

Proposed Reply

Strictly speaking, improvements to the IANA function would be limiting their scope if set into a contract.

We therefore suggest an out of contract continuous self-appraisal process with mid-point review of improvements using the robust multi-stakeholder review process used in ICANN Reviews. This multi-stakeholder model can be utilised, to provide a framework to analyse the issues requiring improvement and create an environment for making consistent and predictable decision, as illustrated in the Final Report of the Delegation, Re-delegation and Retirement Working Group of the ccNSO. (http://ccnso.icann.org/workinggroups/final-report-drd-wg-17feb11-en.pdf)

This improvement process is directly related to our answer in Question 3, whereby the transparency of the IANA Functions Operator in the processing of the delegation and re-delegation of ccTLDs should be improved as the decisions taken by IANA directly affect the local Internet community stakeholders governed by the ccTLD.

To this effect, an “e-IANA” function should be enabled to automate many of the tasks currently performed by IANA and to compartmentalize those functions.

In particular, automated processes should be in place for:

  • adding a new gTLD entry
  • updating of contact details etc.

An increase in transparency would mean that every time an updated ROOT zone is published, a “change-log” is published simultaneously, which incorporates comments on the change request, as well as links to supporting documentation. This will have the potential to increase the visibility of the process and will show the requestor and the process itself.

As a result, any attempts at performing amendments to the ROOT without valid details being entered will result in a red flag situation allowing Root operators to take remedial action.

As a reminder, translation of these documents and reports in the Official UN languages is of paramount importance in the face of the ongoing internationalization of IANA’s functions.

  • No labels

3 Comments

  1. An “e-IANA” function should be enabled to automate many of the tasks currently performed by IANA and to compartmentalize those functions.

    In particular, automated processes should be in place for:

    -        adding a new gTLD entry

    -        updating of contact details etc.

    An increase in transparency means that every time an updated ROOT zone is published, a “change-log” is published simultaneously, which incorporates comments on the change request, as well as links to supporting documentation. This will have the potential to increase the visibility of the process and will show the requestor and the process itself.

    As a result, any attempts at capturing the ROOT or attempts at performing an amendment to the ROOT without valid details being entered will result in a red flag situation allowing Root operators to take remedial action.

  2. The need for more transparency for any attempts to change ROOT zone was among highly discussed items during 40th ICANN meeting in San-Francisco. Especially among participants from Eastern Europe and post-Soviet countries. More over, we need not only automated updates of any attempts to change ROOT zone, as it proposed by Olivier. We need OFFICIAL translation of the most important ICANN/IANA documents into Russian (at least). Because we see a lot of examples of misunderstanding and even misinterpretation of ICANN/IANA terms during "official" translation into local languages.It would be great that national representative in GAC will have personal responsibility for the verification of such translations. It can help to avoid situation with "false" representatives in GAC (as in case with Ukraine, for example)  

  3. Via several Caribbean ALSes in LACRALO:

    Related to the answer in Question 3, whereby the transparency of the IANA Functions Operator in the processing of the delegation and re-delegation of ccTLDs should be improved as the decisions IANA makes directly affect the local Internet community stakeholders governed by the ccTLD.