Skip to main content

ICANN Process Documentation Initiative (Community Feedback Requested)

During ICANN58, Göran Marby talked about starting an effort to describe and document several key processes where the ICANN organization and community interact through recommendations and advice. We've already made some progress, as those of you at the GDD Summit [PDF, 2.3 MB] saw, and wanted to update you before our session at ICANN59.

So far, this effort has resulted in a series of draft flowcharts that visually depict processes, roles and responsibilities, and when applicable, areas where confusion or impasses may arise, starting with:

Community Feedback Requested

As we said, these flowcharts are drafts, and we look forward to working together to determine what we've done right in crafting these, what could be improved and what is missing. Below are a few areas we have identified for discussion and input.

Situations where the Board receives conflicting recommendations or advice from different groups.

  • In preparing recommendations, what mechanism can assist the process to avoid situations where advice goes against recommendations or a policy PDP?

Situations where there is ambiguity in the recommendations or advice, which creates uncertainty in the implementation phase.

  • What steps could be taken to ensure recommendations/advice are clear and implementable, and that implementation is consistent with the intent of the recommendation/advice?
  • After recommendations are sent to the Board, and the team authoring those recommendations has disbanded, what happens when, during implementation efforts, there is ambiguity, confusion or concern regarding the intent or feasibility of the recommendation? The GNSO has a defined process to resolve situations, but how should the ICANN organization and the community resolve those issues in cases where there is no defined process?

What should happen if Reviews result in recommendations that are already topics under discussion in a PDP?

  • How can a process help identify and capture interdependencies between review processes and policy development, and make sure those are flagged early?
  • What processes are needed for review teams to address situations where review team recommendations are intended to direct a PDP effort, or essentially dictate what a policy recommendation should be? What if the PDP group does not agree or does not wish to address the review team's recommendations?

Are there other topics not reflected here that should be included? Do you have any thoughts or feedback to share on the drafts?

During ICANN59, we will be exhibiting the current drafts all week in the main gallery area and holding a session on Thursday, June 29th at 0800 local time in Ballroom 3, to give the community an opportunity to discuss the progress and provide feedback. I encourage you to join this session, in person or via remote participation. We will be discussing the areas above, along with areas of potential confusion or impasse, and this dialogue will help provide further clarity on these processes. If you cannot attend, please submit any feedback on the processes via processdocumentation@icann.org before 30 July 2017.

Next Steps

Feedback on these initial flowchart versions will be gathered through July, with the goal of developing updated versions that incorporate this feedback by ICANN60 in November. The process flowcharts will be maintained online, and a mechanism will be put into place to consistently reflect additional input or clarity to the processes. Beyond that, what happens next will be determined in large part by the input you provide, whether it's at our upcoming session, or via email, as well as the feedback we received from those of you who contributed to the session at the May 2017 GDD Summit. We look forward to working together to finalize this process documentation initiative.

Comments

    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."