Skip to main content
Resources

Minutes | Board Technical Committee Meeting

Board Member and Liaison Attendees: Harald Alvestrand, Avri Doria, Rafael Lito Ibarra, Merike Kaeo, Akinori Maemura (Chair), Kaveh Ranjbar, and Tripti Sinha.

Other Board Members in Attendance: Ron da Silva and Danko Jevtovic.

ICANN Organization Attendees: Adiel Akplogan (Vice President for Technical Engagement), Franco Carrasco (Board Operations Specialist), David Conrad (Chief Technology Officer), John Crain (Chief Security, Stability & Resiliency Office), Dan Halloran (Chief Data Protection Officer and Deputy General Counsel), Vinciane Koenigsfeld (Director, Board Operations), Matt Larson (VP Research, Office of the CTO), David Olive (SVP, Policy Development Support), Wendy Profit (Senior Manager, Board Operations), and Erika Randall (Associate General Counsel).


The following is a summary of discussions, actions taken, and actions identified:

  1. Action Items Review – After establishing the agenda for the meeting, the Committee reviewed the open action items to be addressed by the Committee. The open action items included the following:

    • The preliminary report from the 7 January 2019 Committee meeting has been circulated for the Committee's approval. In an effort to give the Committee enough time to review the preliminary report, the Committee members will provide their approval online.

    • The Committee to work with the Office of the Chief Technology Officer (OCTO) to review the Name Collision Analysis Project (NCAP) proposal and make a recommendation to the Board on the way forward – OCTO gave a presentation on this topic at the Board Workshop and noted that the information provided by the Security and Stability Advisory Committee (SSAC) satisfies the remaining clarifications within their assessment.

    • SSAC session with the Board – ICANN org to intensify the search and identify candidates for the position of technical coordinator for the NCAP. This item will depend on how the Committee decides to move forward with the NCAP proposal.

    • OCTO to add due date for open action items – this item has been completed.

    • OCTO to liaise with the Board Finance Committee and ICANN Finance to assess ICANN org's ability to fund the cost of all the studies (studies 1, 2 and 3) as originally proposed – this item is currently on hold until the Committee makes a recommendation to the Board.

    • The Committee to prepare and send an acknowledgement to the Root Server System Advisory Committee (RSSAC) related to RSSAC037 and RSSAC038 – it was noted that an update would be provided during the meeting.

    • Plan a coordination meeting between SSAC, the Board Technical Committee and OCTO to clarify the remaining points and finalize the scope for study 1 – this item has been completed.

    • Merike Kaeo to contact SSAC to get further clarification on the point raised by OCTO in their revised assessment – this item has been completed.

    • The Committee to share the RSSAC037 and RSSAC038 feasibility assessment and draft implementation planning process with the Board prior to the Los Angeles Board Workshop – this item has been completed.

  2. Board Priority List Check – The Committee appointed a shepherd to each priority item. The shepherds are expected to lead the discussion and work associated with their respective priority item.

    • Action Items:

      • The shepherds assigned to each priority item to start refining the timelines of different activities related to each priority item.

      • The shepherds to prepare amended timelines for each priority item for the next Committee meeting.

  3. Update on RSSAC037 and RSSAC038 – The Committee received an overview on a forthcoming concept paper that discusses RSSAC037 and RSSAC038. The concept paper will be divided into three parts. The first part will discuss the importance of the three-year work and the rational for RSSAC037 and RSSAC038, and the need to have a path forward. The second part will look at the new governance model for the root zone server system based on the documentation, principles and models from the RSSAC advice. The third and final part will be a process to finalize the new governance model with some of the details. Based on RSSAC advice, the new governance model would include three core groups/functions; the first group will recommend policy for the root server system, including SLAs. The second group will review the performance of the root server system and its operators including candidate operators. The third group will only be activated to designate or remove an operator. The path to the new governance model is to conduct public consultation about the end goal and convene a working group of subject matter experts to evaluate the proposal and RSSAC advice. The proposal would eventually go to the larger ICANN community for comment and input and the plan is to have a concrete proposal available by the Kobe meeting so the Committee can have another discussion.

  4. SSAC and NCAP Proposal Update – The Chief Technology Officer (CTO) noted to the Committee that it has obtained sufficient clarifications with regard to potential misunderstandings that might have occurred with the NCAP proposal. The next step is for the Committee to make a recommendation to the Board about how to move forward. The Committee discussed the financial aspects of the project and noted the two proposals. The first is the revised study 1 of the NCAP proposal that estimated the cost to be about $600,000 USD, which would require Board approval. The OCTO version of the study 1 proposal is around $350,000 USD, with a 30% contingency which brings the total to about $430,000 USD; this proposal would not require Board approval, but would still need discussion within the context of the Board Finance Committee. The Committee is in the process of making a decision and hope to have one by the next ICANN meeting in Kobe, Japan.

  5. Information Transparency Initiative Update – The CTO provided the Committee with a description of the intended deliverables for the April 2020 launch of the Information Transparency Initiative (ITI). All the content from icann.org will be migrated to and surfaced in the new document management system based upon a new information architecture with a new navigation mechanism. The content will be tagged and the tags will be multilingual. There will be a multifaceted search mechanism that allows people to find the tagged material. The content that has been built internally will be done using a new authoring system that works with the document management system (DMS) which will have enforced work flows. Staff will be trained on the authoring system and will have the ability to author their own content. A number of features that currently exist on icann.org will be reimplemented; things like public content, a content subscription service, what use to be known as MyICANN, an events calendar and some of the forms.

    The Committee was presented with a timeline of the development work on the ITI. The intent is to release a beta version with some of the registry agreements so that individuals interested in registry agreements can see these agreements on the new website and try out the new search functionality. Currently, work is being done to migrate all the Board and legal content. In May, work will begin on the public comments portion. From July through October, work will be focused to revising the site map, navigation, information architecture, and home page along with the new search functionality. From October through January, work will be focused on features, which are content subscriptions, calendar, google analytics and some of the forms.

    The Committee got a glimpse of some sample pages detailing the ITI improvements. Currently, the ITI team is focused on the foundational improvements including deploying the DMS, reimplementing the content management system (CMS), putting in the underlying technical infrastructure on top of which everything else is built. As a part of that, the ITI team has also built a few content types which are the announcements and blogs, Board materials, legal content, and public comment. These content types will be pages that people will go to in the new icann.org and each one will be an independent project. Once the underlying infrastructure has been built, there will be a prioritization process to identify what content should be migrated first. OCTO noted that ICANN org's other web properties, including the Supporting Organization and Advisory Committee (SO/AC) sites will also be rebuilt using ITI's infrastructure and benefit from its improved technical and information architecture. The maintenance plan post April 2020 will require the assistance of outside contractors. ICANN org has engaged Zia for the DMS and Architect for the CMS. Between now and April, OCTO will need to build up the internal resources to manage these contractors.

    The Committee also received a briefing on some of the risks and mitigation efforts associated with the project. First, OCTO noted the full cost and anticipated duration of the project appears to have been underestimated. In order to meet time and cost targets, the ITI team is looking at refining the project scope. Second, OCTO has encountered a bit of a challenge in identifying qualified developers; however, they have identified a senior java developer and a formal letter has been sent out. Third, in the maintenance plan, OCTO has identified three additional resources that they will need to bring in including technical writers and graphic designers. This is something OCTO is still working on. Fourth, there are a lot of terms within the ICANN org universe that need to be embedded into the taxonomy and as a result, the consolidation of the taxonomy is taking longer than expected. OCTO is trying to prioritize things internally in an effort to push some of the information architecture work into later cycles. The fifth and final risk is related to the ITI vendors. The CMS vendor, Architect, has experienced a high turnover internally which made it difficult to keep track of their staff. Zia, the Alfresco vendor, while meeting speed requirements, lacking quality in their output. To help mitigate this risk, OCTO intends on making the migration earlier than anticipated so that some of the work the contractors are doing can be moved in-house.

    OCTO noted that due to lack of attendance during ICANN63, there will be no public session on ITI during ICANN64. Instead, there will be targeted sessions with newcomers and SO/ACs.

  6. Consideration of APWG Proposal to hash PoC in public WHOIS – The Committee discussed the Anti-Phishing Working Group (APWG) proposal and agreed that the technical and operational implications suggests that the proposal should be reviewed by third party experts. The Committee also discussed sharing the proposal with the Technical Study Group (TSG), SSAC and Expedited Policy Development Process (EPDP) for their opinions. The SSAC option was quickly rejected since one of the authors of the APWG proposal is a member of the SSAC.

  7. DNS Evolution & Security – The Committee briefly discussed putting together a draft list of the ecosystems that may be subject to DNS attacks. A session discussing best practices on securing the DNS ecosystem is scheduled for the Kobe meeting. The Committee hopes to continue these discussions in Kobe.

  8. Any Other Business (AOB) – The Committee agreed to provide default permission to share any RSSAC-related matters with RSSAC unless the materials are designated for Committee members only. The Committee briefly discussed readjusting the timeline for the discussion on the L root strategy. The Committee also agreed on having an in-person meeting in Kobe, in the Board workshop.

The Chair called the meeting to a close.

Published on 9 March 2019

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."