Update from ICANN on definition section of the IANA Naming Functions Contract
Hello all, I had the opportunity to meet with Sam Eisner from our Legal team at ICANN and Kim Davies to address some of the questions you had that related to the definitions section of the contract. Ahead of our next call on Tuesday, please review the message Sam drafted that I believe explains a lot of the background and reasoning as to why the terms are defined the way they are. We believe that this information will allow the group to move into the next step of your review. During this phase, myself or someone from PTI/ICANN could provide more operational briefings, as it will be with the full context of each section/deliverable. From Sam Eisner, ICANN’s Deputy General Council: “Dear IFRT, We wanted to provide you some background on the genesis of the definition section within the IANA Naming Function Agreement (the “Agreement”). In many ways, the definition section is the last section drafted within the agreement. A definition section can be at the front or at the back of the agreement, and the function is to make sure that there’s a comprehensive listing of the defined terms – including acronyms and other short form references – that are used within a contract. When drafting the Agreement, the baseline was that many provisions were carried over from the IANA Functions Contract that ICANN previously maintained with the NTIA, as recommended by the Cross-Community Working Group on the IANA Stewardship naming function (CWG-Stewardship). The CWG-Stewardship was provided with external counsel from the law firm of Sidley Austin that ultimately worked with ICANN and ICANN’s outside counsel, Jones Day, to make sure the CWG-Stewardship recommendations were faithfully recorded within the Agreement. The main focus was on drafting of the actual terms of the Agreement to reflect the full intended scope of the IANA Naming Function. As we drafted the Agreement – as is typical – we would define terms along the way and make reference to short forms for frequently used terms such as gTLDs, ccTLDs, NS records, and others. We also referenced foundational documents, such as the 2005 Governmental Advisory Committee Principles and Guidelines for the Delegation and Administration of Country Code Top Level Domains (defined as “GAC 2005 ccTLD Principles”). At the end of the drafting, we then went through and pulled out all of the defined terms used within the Agreement to reflect them within the Definition section. The Definition section therefore includes defined terms that are meant to be read within the context of the Agreement and where they appear within the Agreement. For example, the Agreement includes specific definitions of the terms “Delegation”, “Transfer”, and “Revocation” that are limited to application to ccTLDs. This was intentional, as one of the important principles that emerged was that the Agreement should fully embrace the terms of the Framework of Interpretation, which were fairly new at the time. If you read the defined terms within the context of where they appear in the Agreement, there is very intentional usage of those defined terms only in reference to ccTLD-related obligations. The definitions are NOT trying to define the full scope of how each term is used within the IANA Naming Function. For example, at Annex A, Section 1.d, you’ll see that the defined terms are used to define the scope of PTI’s work for ccTLDs, and then uses the more general term “delegation” later in that same section for gTLDs. The difference is in the use of the defined (i.e., capitalized) term as opposed to the more general (i.e., not capitalized) term. In populating the Definition section, the drafters also made choices to maintain the cohesiveness of the document and reduce potential for inconsistencies. When populating Definitions, if the definition of the term had already been spelled out within the text of the Agreement, we made reference to that section of the Agreement as opposed to duplicating the definition or moving the definition only to the Definition section. Particularly due to the length of the Agreement, we did not want to force readers to have to refer back to the beginning in all instances to understand what a defined term might mean. In addition, where the term is defined outside of the Agreement, we included reference to the source document for that definition, again as a way to make sure that the IANA Naming Function Agreement is always understood within the context of the source documentation, such as the PTI Bylaws, and we are not causing any unintended inconsistency. Please let us know if further discussion or information might be helpful.” Thanks everyone, Marilia Hirano Director, IANA Strategic Programs and PTI Liaison to the IFR2 team Internet Corporation for Assigned Names and Numbers (ICANN) www.icann.org<http://www.icann.org> Email: marilia.hirano@iana.org<mailto:marilia.hirano@iana.org> Phone: +1 (310) 804-3549
Thank-you Marillia, This is helpful input and context and a reminder of quite how well-resourced the IANA Transition was; ICANN Legal, CWG Legal (Sidley Austin) and Jones Day plus very active involvement of experienced and well-informed members of the ICANN Community. Jonathan From: IFR2-team <ifr2-team-bounces@icann.org> On Behalf Of Marilia Hirano Sent: Monday, April 15, 2024 5:18 PM To: IFR2-team@icann.org Subject: [IFR2-team] Update from ICANN on definition section of the IANA Naming Functions Contract Hello all, I had the opportunity to meet with Sam Eisner from our Legal team at ICANN and Kim Davies to address some of the questions you had that related to the definitions section of the contract. Ahead of our next call on Tuesday, please review the message Sam drafted that I believe explains a lot of the background and reasoning as to why the terms are defined the way they are. We believe that this information will allow the group to move into the next step of your review. During this phase, myself or someone from PTI/ICANN could provide more operational briefings, as it will be with the full context of each section/deliverable.
From Sam Eisner, ICANN’s Deputy General Council:
“Dear IFRT, We wanted to provide you some background on the genesis of the definition section within the IANA Naming Function Agreement (the “Agreement”). In many ways, the definition section is the last section drafted within the agreement. A definition section can be at the front or at the back of the agreement, and the function is to make sure that there’s a comprehensive listing of the defined terms – including acronyms and other short form references – that are used within a contract. When drafting the Agreement, the baseline was that many provisions were carried over from the IANA Functions Contract that ICANN previously maintained with the NTIA, as recommended by the Cross-Community Working Group on the IANA Stewardship naming function (CWG-Stewardship). The CWG-Stewardship was provided with external counsel from the law firm of Sidley Austin that ultimately worked with ICANN and ICANN’s outside counsel, Jones Day, to make sure the CWG-Stewardship recommendations were faithfully recorded within the Agreement. The main focus was on drafting of the actual terms of the Agreement to reflect the full intended scope of the IANA Naming Function. As we drafted the Agreement – as is typical – we would define terms along the way and make reference to short forms for frequently used terms such as gTLDs, ccTLDs, NS records, and others. We also referenced foundational documents, such as the 2005 Governmental Advisory Committee Principles and Guidelines for the Delegation and Administration of Country Code Top Level Domains (defined as “GAC 2005 ccTLD Principles”). At the end of the drafting, we then went through and pulled out all of the defined terms used within the Agreement to reflect them within the Definition section. The Definition section therefore includes defined terms that are meant to be read within the context of the Agreement and where they appear within the Agreement. For example, the Agreement includes specific definitions of the terms “Delegation”, “Transfer”, and “Revocation” that are limited to application to ccTLDs. This was intentional, as one of the important principles that emerged was that the Agreement should fully embrace the terms of the Framework of Interpretation, which were fairly new at the time. If you read the defined terms within the context of where they appear in the Agreement, there is very intentional usage of those defined terms only in reference to ccTLD-related obligations. The definitions are NOT trying to define the full scope of how each term is used within the IANA Naming Function. For example, at Annex A, Section 1.d, you’ll see that the defined terms are used to define the scope of PTI’s work for ccTLDs, and then uses the more general term “delegation” later in that same section for gTLDs. The difference is in the use of the defined (i.e., capitalized) term as opposed to the more general (i.e., not capitalized) term. In populating the Definition section, the drafters also made choices to maintain the cohesiveness of the document and reduce potential for inconsistencies. When populating Definitions, if the definition of the term had already been spelled out within the text of the Agreement, we made reference to that section of the Agreement as opposed to duplicating the definition or moving the definition only to the Definition section. Particularly due to the length of the Agreement, we did not want to force readers to have to refer back to the beginning in all instances to understand what a defined term might mean. In addition, where the term is defined outside of the Agreement, we included reference to the source document for that definition, again as a way to make sure that the IANA Naming Function Agreement is always understood within the context of the source documentation, such as the PTI Bylaws, and we are not causing any unintended inconsistency. Please let us know if further discussion or information might be helpful.” Thanks everyone, Marilia Hirano Director, IANA Strategic Programs and PTI Liaison to the IFR2 team Internet Corporation for Assigned Names and Numbers (ICANN) <http://www.icann.org> www.icann.org Email: <mailto:marilia.hirano@iana.org> marilia.hirano@iana.org Phone: +1 (310) 804-3549
participants (2)
-
Jonathan Robinson -
Marilia Hirano