Go back

Secretary's Notice | Secretary's Notice of PTI Board Action Without a Meeting | 27 March 2019

Secretary's Notice | Secretary's Notice of PTI Board Action Without a Meeting

EFFECTIVE DATE: 27 March 2019

THE PTI BOARD PASSED THE FOLLOWING RESOLUTION EFFECTIVE 27 MARCH 2019 BY UNANIMOUS CONSENT, WITHOUT A MEETING, PURSUANT TO THE PTI BYLAWS AT:

Section 5.15 ACTION WITHOUT MEETING

Any action required or permitted to be taken by the Board may be taken without a meeting, if (a) all Directors, individually or collectively, consent in writing to the action and (b) the number of Directors then in office constitutes a quorum as set forth in Section 5.11.1, which, for the avoidance of doubt, requires a majority of Directors then in office including at least one ICANN Director and at least one Nominating Committee Director. Such written consent shall have the same force and effect as a unanimous vote of the Board taken at a meeting. Such written consent or consents shall be filed with the minutes of the proceedings of the Board.

Written consent may be transmitted by first-class mail, messenger, courier, facsimile, e-mail or any other reasonable method satisfactory to the Chairperson or the President.

ALL VOTING MEMBERS RESPONDED AND CONSENTED TO THE FOLLOWING RESOLUTION BY ELECTRONIC MEANS:

Approval of the Amendment to the IANA Naming Function Contract

Whereas, the ICANN Bylaws, at Section 16.3, require ICANN and PTI to maintain an IANA Naming Function Contract [PDF, 283 KB] for PTI's performance of the IANA naming function. The initial IANA Naming Function Contract was approved by both the ICANN and PTI Boards in 2016 as part of the IANA Stewardship Transition.

Whereas, the IANA Naming Function Contract currently includes a table specifying detailed, operational Service Level Agreements (SLA Table) as agreed with the multi-stakeholder community during the IANA Stewardship Transition process.

Whereas, ICANN org, PTI and the Customer Standing Committee have all identified that requiring a modification to the IANA Naming Function Contract every time that an individual SLA needs to be modified, deleted or added is not sustainable and does not serve the needs of ICANN, PTI or the customers of the IANA Naming Function. Therefore, a proposal was reached to amend the IANA Naming Function Contract one time in order to move the SLA Table to outside of the Contract, and to require any changes to said SLAs to follow a community approved and published "Process for Amending the IANA Naming Service Level Agreements".

Whereas, ICANN org, PTI and the CSC participated in the development of the Process for Amending the IANA Naming Service Level Agreements, and the CSC socialized that process with the customers of the IANA Naming Function.

Whereas, ICANN solicited public comment on the proposed Naming Function Contract amendment to the IANA Naming Function Contract from 7 January 2019 to 18 February 2019.

Whereas, the public comment forum for the proposed amendment to the IANA Naming Function Contract closed on 18 February 2018, with ICANN receiving one comment from the Registries Stakeholder Group supporting the proposed amendment. A summary and analysis of the comments was published on 25 February 2019 and provided to the Board.

Whereas, on 14 March 2019 the ICANN Board approved for ICANN to enter into the proposed Amendment.

Resolved (PTI.2019.03.27.01), the proposed Amendment No. 1 to the IANA Naming Function Contract is approved, and the PTI President, or his designee(s) is authorized to take such actions as appropriate to finalize and execute the Agreement.

Rationale for Resolution PTI.2019.03.27.01:

The Customer Standing Committee (CSC), working with ICANN org and PTI, has recommended changes based on evidence from accrued operational data. In proposing that the SLAs be moved from the contract to a SLA table on a PTI webpage, it was recognized that a comprehensive SLA change process was required to ensure that appropriate consultations with the IANA Function naming customers and broader ICANN community occur.

In the CSC's meeting held on 17 December 2018, it approved the two SLA change processes: a 'Process for amending the IANA Naming Function Service Level agreements' and a 'Procedure for Modifying the process for amending the IANA Naming Function Service Level agreements'. ICANN org and PTI management were involved in the conversations and agree to the processes as well. The processes are not in force until such time as the naming function contract is amended.

The Board is approving the amendment to the IANA Naming Function Contract at this time because moving IANA Naming Function SLAs from the contract to a SLA table on a webpage allows SLA changes to more efficiently meet the needs of naming customers, while adherence to the new "Process for Amending the IANA Naming Service Level Agreements" ensures all such changes follow a strict process to ensures appropriate levels of community consultation and agreement between the CSC and ICANN/PTI.

The Board's action takes into consideration input from the community, which supported the amendment through the CSC's approval, as well the RySG's public comment which stated that "This amendment to the IANA Naming Functions Contract adopts an SLA Change Process that was cooperatively developed and agreed to by the CSC, PTI, and ICANN org. The SLA Change Process will allow the CSC and PTI to a) modify SLAs where appropriate b) add new SLAs as new services come on-line and, c) remove SLAs not warranted anymore. The RySG supports the Amendment and requests the ICANN Board to approve the Amendment so that SLAs that currently need to be modified or added or removed may be accomplished as soon as possible."

The action directed in this resolution will not have any further impact on PTI's resources or the security and stability of the DNS. This action is within PTI's mission as it supports PTI's performance of the IANA naming functions.

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