ICG Questions – Draft Responses
From ICG request:
We are requesting responses to these questions ideally by 7 October at 23:59 UTC (prior to the ICG’s final call before ICANN 54 on October 8), or by 14 October at 23:59 UTC if the CWG requires more time. We realize this is an aggressive timetable, so please keep us informed if you feel you need further time.
Some of the questions below include requests or suggestions for amendments to the text of the CWG proposal as reflected in Part 1 of the combined proposal. The ICG would like to state explicitly that we do not expect a further ICG public comment period to be necessary on the combined proposal if these amendments are made. While the ICG reserves the right to seek further public comment if we receive extensive amendments from the operational communities, we do not expect to do so at this time.
Question | Draft Response | Comments/Status | ||||||||||||||||||||||||
RZM 1) Due to concerns expressed in the public comment period, the ICG asks the CWG-Stewardship to inform us whether or not the Verisign/ICANN proposal (available athttp://www.ntia.doc.gov/files/ntia/publications/root_zone_administrator_proposal-relatedtoiana_functionsste-final.pdf) for revising Root Zone Management arrangements after the elimination of NTIA's authorization role meets the CWG's requirements as expressed in paragraph 1150 (sections 2 and 3) and multiple Annexes of Part 1 of the transition proposal. | The Verisign/ICANN proposal is not a vehicle for amending or replacing the Cooperative Agreement. Instead, their proposal is about how to implement and test the logistical elimination of NTIA approvals at the moment of transition in order to minimize risk.
The Verisign/ICANN proposal addresses only paragraph 1150, Section 1. Section 2 has not, to the CWG-Stewardship’s knowledge, been addressed but the CWG-Stewardship agrees that an arrangement must be in place at the time of transition. The CWG-Stewardship understands that a separate and parallel process is occurring to deal with that particular aspect. | Updated as per CWG-Stewardship meeting. | ||||||||||||||||||||||||
RZM 2) The names part of the proposal contains subtle but significant discrepancies in the way it describes the roles of the IANA Functions Operator (IFO) and the Root Zone Maintainer (RZM). It also seems to contain different requirements for a process to change those roles. Paragraph 158 in Part 1 of the transition proposal describes the RZM and the IANA functions operator as separate “roles” with distinct functions, and says "should there be proposals to make changes in the roles associated with Root Zone modification, that such proposals should be subject to wide community consultation." On the other hand Annex S, the Draft Proposed Term Sheet (page 136), describe the IFO and RZM as "two roles that are performed by two different entities," and adds "any amendment to the roles and responsibilities of PTI and the RZM ... will require approval of the ICANN board [and the members of ICANN or a special IFR].” Which of these two approaches better reflects the consensus of the names operational community: the one embodied in Annex S or the one embodied in paragraph 158? Paragraph 158 does not clearly rule out having the RZM and IFO in the same organization, as long as the "roles" and "functions" are distinct. Whereas Annex S suggests (in bracketed language) that any change or merger in the roles would be subject to community accountability, 158 suggests only a “wide community consultation.” The ICG would like to know what is meant by a wide community consultation. Is it the same as a public comment period? Does it also imply that wide community consensus would be necessary before making the change? The CWG is requested to provide comment or clarification for any further action, as appropriate. | Both descriptions are correct but incomplete. The full answer is addressed in paragraph ICG 1155. A change in the responsibilities of the IANA Functions Operator and the Root Zone Maintainer is clearly a substantial architectural and operational change, and is therefore subject to a review of the Standing Review Committee and ultimately ICANN Board approval. Subsection 5 of paragraph 1155 requires consultation through an ICANN Public Comment proceeding. | Per CWG-Stewardship meeting #68, this question/answer is considered complete. | ||||||||||||||||||||||||
ccTLDs 3) We received comments on Section P1.II.A.i., “Affected IANA Service (ccTLDs)” about the references to Internet Coordination Policy 1 (ICP-1) and the work of the Framework of interpretation Working Group (FOIWG). The ICANN Board has adopted the recommendations in the report of the FOIWG and so paragraph 1027 could usefully be amended to reflect this, replacing the last sentence with “The ICANN Board adopted the FOIWG recommendations in June 2015.” Please let us know if you agree to this amendment. | We agree that paragraph 1027 could usefully be amended, replacing the last sentence with "The ICANN Board adopted the FOIWG recommendations in June 2015". | Per CWG-Stewardship meeting #67, this question/answer is considered complete. | ||||||||||||||||||||||||
ccTLDs 4) The ccNSO Council has requested an editorial change, which can be achieved by removing the reference to ICP-1 in section 1036 and including a footnote referencing the removal clearly indicating the non-status of ICP-1 as well as News Memo 1 and GAC Principles from 2000 (the last of these having been formally superseded by the GAC Principles 2005). This appears to be a friendly drafting amendment, bringing the document into line with recently updated policy and we would therefore ask the CWG whether Part 1 of the combined proposal could be adapted accordingly. If the CWG agrees to adapt its proposal, please send us verbatim text for paragraph 1036 and any associated footnotes so that we know precisely how to edit the text in the combined proposal. | Proposed text to replace paragraph 1036: References to documentation of policy development and dispute resolution processes (ccTLDs)
Footnote: ICANN staff drafted two documents entitled "ICP-1" (May 1999) and "CCTLD News Memo #1" (23 October 1997) which were the source of significant friction between ICANN and the ccTLD community and the Country Code Names Supporting Organization (ccNSO). The ccNSO formally rejected the ICP-1 document (final report of the ccNSO's Delegation and Redelegation Working Group or DRDWG) arguing that it modified policy but did not meet the requirements for doing so at the time of its introduction in 1999. ICANN has accepted that ICP-1 and CCTLD News Memo #1 were not fit for purpose and have archived the documents. | Per CWG-Stewardship meeting #67, this question/answer is considered complete. | ||||||||||||||||||||||||
ccTLDs 5) We have also received a comment on the composition of IANA Function Review Teams (paragraph 1283). This recommends that two ccNSO members and one non-ccNSO ccTLD member be appointed to the IFRT. While the input supported the objective of encouraging the participation of non-ccNSO ccTLDs, it recognised that it could be difficult to ensure rotation of the non-ccNSO ccTLD member. In particular, the commentator stressed that regional balance should be considered an important criterion and suggested that the recommendation be changed to make the one non-ccNSO ccTLD member recommendation a target, rather than a requirement. If the CWG agrees with this suggestion and wishes to amend its proposal, please send us verbatim text to reflect the associated amendment. | The CWG-Stewardship has proposed (Annex F) an inclusive community group as the IANA Functions Review Team (IFRT) to periodically review (the first within 2 years; every five years thereafter) the performance of the IANA functions operator and to ascertain if there is a need to change IANA's statement of work. Text from the current document: "The IANA Function Review Team will be composed as follows:
Supporting Organizations or Advisory Committees, in accordance with their respective internally defined processes, will appoint individuals who have submitted Expressions of Interest. In the case of the non-ccNSO ccTLD representative, the ccNSO will be the appointing body; in appointing the non-ccNSO representative it is strongly recommended that the ccNSO also consult with the Regional ccTLD Organizations, namely AfTLD, APTLD, LACTLD, and CENTR".
Consequently, (s)electing geographical diverse representatives to the IFRT is achievable. Further, the above composition ensures that the diverse user community is represented and respected in the IANA performance review. The ccNSO currently comprises 156 ccTLD Registry members out of a total of 254 ccTLD Registries, so there are a significant number of ccTLD Registries that are not members of the ccNSO for specific reasons. In addition, there may be current registry members of the ccNSO who may subsequently decide to leave the ccNSO and become non-ccNSO member ccTLD Registries. Respect for the diversity of the ccTLD community was appreciated and accommodated by the members of the CWG-Stewardship when preparing their proposal, making it a requirement that a single seat on the IFRT for non-ccNSO Registries be made a requirement. Further, the diversity of the ccTLD community was recognized by the ccNSO when the ccNSO Council unanimously approved CWG-Stewardship's proposal and also by the other Chartering Organizations each approving the proposal. After more than one year of public debate, two CWG-Stewardship consultations, community discussions (both on-line and in person) and the subsequent approval of the CWG-Stewardship Proposal by the respective Chartering Organizations; making such a fundamental change to the composition of the IFRT would be inappropriate. We wish to assure an important section of the ccTLD registry community of their right to be a member of the IFRT, and thereby uphold our core object of providing an inclusive non-discriminatory IFRT process. Consequently, there should be no change to the CWG-Stewardship's submission and the (s)election and composition of the IFRT membership should remain as described in the current document. | Per CWG-Stewardship meeting #67, this question/answer is considered complete. | ||||||||||||||||||||||||
PTI 6) The three operational communities have a long history of cooperation as needed to help ensure the smooth functioning of the DNS and the Internet. A number of comments were concerned that the three IANA functions could end up being carried out by different operators and suggested that there was a need for some information exchange and coordination between the operational communities to ensure a proper understanding of the impact a change might have on the operation of the other functions (perhaps because of interdependencies between the functions or because of shared resources or key staff). This information exchange might also help in coordinating action in the case of remedying operational difficulties. For this to work, the three operational communities need to commit to coordinating and cooperating as necessary when changing operator, whether by leveraging existing coordination mechanisms or new ones. Can the names operational community provide such a commitment? If so, the ICG intends to reflect that and the commitments of the other communities in Part 0 of the transition proposal. | The CWG-Stewardship would hereby like to express its commitment on behalf of the naming community to co-ordinate and co-operate as necessary when changing operator, whether by leveraging existing coordination mechanisms or new ones. | Per CWG-Stewardship meeting #67, this question/answer is considered complete. | ||||||||||||||||||||||||
PTI 7) Please could you clarify whether or not compliance by ICANN and/or PTI is mandatory when decisions or recommendations are made by an IFR or Special IFR process. | The CWG-Stewardship notes that the proposal only requires that the Board and the Community come to an agreed upon resolution to the IFR or Special IFR recommendations. The sense of the CWG-Stewardship is that there is the expectation that such recommendations would be implemented. In the event that there is divergence between the Board and the Community on an IFR decision or recommendation, the Community will be able to rely on mechanisms that the CCWG-Accountability is currently developing. | Updated according to CWG-Stewardship meeting #68 discussion. | ||||||||||||||||||||||||
PTI 8) Comments regarding the PTI board fall in two broad categories, one about the board’s powers and another one about which members get selected to the board and how. Some of the comments have differing suggestions as to what the actual member selection process should be. We note that the board composition and selection procedures have been extensively discussed within the CWG and should be elaborated in detail during the implementation phase. Paragraph 112 of the proposal says: “As a separate legal entity, PTI will have a board of directors and have the minimum statutorily required responsibilities and powers.” This phrasing implies that it is the PTI itself rather than the PTI board that will have "the minimum statutorily required responsibilities and powers.” However, from the underlying legal expertise (from Sidley) we read the minimum statutorily required responsibilities and powers as being applied to the PTI board. We’d like to ask the CWG whether this interpretation is correct. If so, we would propose amending the sentence by replacing “and” with “who” as follows: “As a separate legal entity, PTI will have a board of directors who have the minimum statutorily required responsibilities and powers.” | The CWG-Stewardship confirms that the interpretation as stated by the ICG (the PTI Board will have the “minimum statutorily required responsibilities and powers”) is correct. | Per CWG-Stewardship meeting #67, this question/answer is considered complete. | ||||||||||||||||||||||||
PTI 9) Some comments raise concerns in the context of the proposed PTI board composition (mix of ICANN employees and independent directors) that the ICANN board and the PTI board could attempt to avoid responsibility for any operational shortcomings by each seeking to hold the other board responsible. Paragraph 113 in Part 1 indicates that the PTI board will be responsible for ensuring that the PTI "fulfills its responsibilities under the IANA functions contract with ICANN.” Could the CWG provide an unambiguous statement as to which of the two boards will ultimately be held accountable for ensuring that the IANA functions are carried out appropriately? Please include verbatim text amendments to Part 1 if you believe that would be appropriate to clarify this point. | As stated in the CWG-Stewardship proposal, the PTI Board will be responsible for ensuring that PTI fulfills its responsibilities under the IANA Functions Contract with ICANN. However, should the PTI Board not perform its responsibilities, the ICANN Board, will hold the PTI Board accountable. As noted in the proposal, as part of the implementation process it is anticipated that a contract would be established between PTI and ICANN that will grant PTI the rights to act as the IFO, and set out the rights and obligations of PTI and ICANN. The CWG-Stewardship recommends to clarify paragraph 113 as follows (additional language highlighted in yellow): “The function of the PTI Board is to provide oversight of the operations of PTI in order to ensure that PTI meets, at a minimum, applicable statutory requirements under California public benefit corporation laws and, importantly, fulfills its responsibilities under the IANA functions contract with ICANN. If the PTI Board does not fulfill its oversight responsibilities with respect to the operations of PTI, the ICANN Board will hold the PTI Board accountable by exercising the rights ICANN has as the member of PTI and as the counterparty to the IANA functions contract with PTI.” | Per CWG-Stewardship meeting #68, this question/answer is considered complete. | ||||||||||||||||||||||||
Scope 10) The CWG-Stewardship proposal uses the terms "IANA Functions Operator" and "IFO" in a way that appears to refer to the operator of the IANA Naming Functions, and not necessarily to the operator of other IANA functions, such as the IANA Numbering Functions or the IANA Protocol Parameters Functions. Please could you clarify whether or not these terms, in the CWG-Stewardship proposal, are intended to refer only to the names portion of the IANA functions. | The CWG-Stewardship confirms that in the context of the CWG-Stewardship proposal the terms such as IANA Functions Operator and IFO are intended to only refer to the names portion of the IANA functions. | Per CWG-Stewardship meeting #67, this question/answer is considered complete. | ||||||||||||||||||||||||
Scope 11) Please could you clarify whether or not the Customer Standing Committee (CSC) applies only to the names portion of the IANA functions. | The CWG-Stewardship confirms that the Customer Standing Committee (CSC) applies only to the names portion of the IANA functions. | Per CWG-Stewardship meeting #67, this question/answer is considered complete. | ||||||||||||||||||||||||
Scope 12) Please could you clarify whether or not the IANA Functions Review (IFR) and Special IFR apply only to the names portion of the IANA functions. | The CWG-Stewardship confirms that the IANA Functions Review (IFR) and Special IFR apply only to the names portion of the IANA functions. |
Per CWG-Stewardship meeting #67, this question/answer is considered complete. | ||||||||||||||||||||||||
Scope 13) The .ARPA domain is used for special purposes. Please could you clarify whether or not the .ARPA domain will be included in the CSC and IFR processes. | The CWG-Stewardship proposal includes a place for the .ARPA domain in the CSC and the IFR processes, should .ARPA choose to participate.
In the CSC process, “one additional TLD representative not considered a ccTLD or gTLD registry operator such as the IAB for .ARPA could also be included in the minimum requirements but is not mandatory”. Should the TLD be interested in participating, the operator would be required to go through the selection process outlined in the CSC Charter.
In the composition of the IFR Team, there is a role reserved for a CSC Liaison, which could, but is not required to, be the .ARPA domain. | Per CWG-Stewardship meeting #68, this question/answer is considered complete. |
