Skip to main content

Technical Study Group Publishes TSG01: Technical Model for Access to Non-Public Registration Data

Technical study group

We are pleased to inform you that the Technical Study Group on Access to Non-Public Registration Data (TSG) completed its work, on schedule. In March, the TSG published a Draft Technical Model for community review, which received substantive feedback at ICANN64 in Kobe, Japan and via written comments after ICANN64. The TSG's final output, "TSG01, Technical Model for Access to Non-Public Registration Data," reflects updates and revisions to its prior work.

We reviewed and considered all comments and feedback. These comments allowed us to clarify our intent, simplify the Technical Model, remove extraneous or misleading material, update every section, add frequently asked questions and a Future Work section, and integrate new concepts. We engaged with representatives from Europol, who provided feedback on implementation considerations of the Technical Model. Further, ICANN President and CEO Göran Marby briefed us on his meetings in Brussels with the European Commission.

In addition to TSG01, the TSG is also publishing a report that provides specific responses to all written feedback received prior to April 29, 2019.

We have now submitted TSG01 to the ICANN CEO. Göran and his team at ICANN org will use the model in discussions with the European Commission and the European Data Protection Board to determine whether a unified access model based on the Technical Model reduces legal liability for the contracted parties. The TSG will remain available for a few months to clarify or answer questions that arise from Göran's consultations, if necessary.

Completing such a significant piece of technical work in four months demanded dedication, discipline and focus. I am deeply grateful to the subject matter experts who constituted my team, and to the amazing staff members at ICANN org who enabled the TSG to work without impediment. To paraphrase Göran, the work of our team was possible because we were delivery driven, rather than agenda driven. In March, community members and leaders approached us to share what made the TSG effort successful. We plan to provide a "What Worked" document that might serve as a model for success in future technical work inside the ICANN community.

Personally, this has been a satisfying project, especially because we have now laid to rest skepticism about the technical feasibility of the access model. Much more work, especially on the policy side, remains to be done, and we wish those tackling this complex yet vitally important problem in the domain name system all the best.


    kurtberk  19:36 UTC on 15 May 2019

    Very good post...

    JMB Davis Ben-David  04:26 UTC on 29 January 2020

    Thanks for such existing post . I appreciate that your post is really informative.

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"""" is not an IDN."