.COm 註冊協議
(2024年12月1日)
註冊協議
本註冊協議（以下稱為「本協議」）由互聯網名稱與編號指派公司（Internet Corporation for Assigned Names and Numbers，簡稱「ICANN」），一家加州非營利公共利益公司，與VeriSign, Inc.，一家特拉華州公司（簡稱「Verisign」）於2024年12月1日簽訂。本協議全面修改並取代2012年12月1日ICANN與Verisign之間的註冊協議，該協議經過於2016年10月20日對.CO m註冊協議的第一次修訂、於2019年3月27日對.CO m註冊協議的第二次修訂，以及於2020年3月27日對.CO m註冊協議的第三次修訂（合稱「之前的協議」）。
第一條 簡介
第1.1節 生效日期. 本協議的「生效日期」為2024年12月1日。
第1.2節 頂級域名. 本協議適用的頂級域名為.com（"TLD"）。
第1.3節 指定為登記運營商. 在生效日期起，並在本協議第4.1節定義的期限內，除非根據本協議第6條提前終止，ICANN將繼續指定Verisign為該TLD（"登記運營商"）的唯一登記運營商。
第二條 代表和保證
2.1章節 登記運營商的陳述與保證.
(a) 組織; 充分授權與執行. 登記運營商是一家根據特拉華州法律正式組織、有效存在並且良好運作的公司，並且登記運營商擁有簽訂本協議的所有必要權力與授權。登記運營商已獲得進入本協議所需的所有公司批准和行動，且本協議亦已由登記運營商正確及有效地執行及交付。
(b) 談判過程中所作的陳述. 雙方在談判本協議過程中所作的事實陳述，在作出時在所有重要方面均為真實和正確。違反或侵害本小節不應成為終止、撤回或其他公平救濟的依據，而僅應引起損害賠償的請求。
第2.2節 ICANN的陳述與保證.
(a) 組織；授權及執行. ICANN是一家經加州法律正式組織、有效存在並且良好運作的非盈利公共利益公司。ICANN擁有所有必要的公司權力和權限來簽訂本協議。ICANN進入本協議所需的所有公司批准和行動均已獲得，且本協議已由ICANN適當且有效地執行和交付。
第三條 約定
1
第3.1節 登記機構的約定. 登記機構與ICANN約定及同意如下：
(a) 維護安全及穩定.
(i) ICANN臨時規範或政策。登記機構應遵守並實施ICANN董事會暫時建立的所有規範或政策，前提是得到ICANN董事會以至少三分之二會員投票通過的批准，只要ICANN董事會合理認為立即暫時建立該主題的規範或政策是必要的，以維持登記服務或DNS的穩定性或安全性（如第3.1(d)(iv)(G)節所定義）。該提案的規範或政策應盡可能具體地制定以實現這些目標。在根據本條款建立任何規範或政策時，ICANN董事會應陳述該規範或政策臨時採納的時間期限，並應立即實施ICANN章程中所載的共識政策發展過程。ICANN還應發佈一份諮詢聲明，其中包含對其採納臨時規範或政策的詳細解釋及為何董事會認為該規範或政策應獲得互聯網利益相關者的共識支持。如果該規範或政策的採納時間超過90天，ICANN董事會應每90天重新確認其臨時採納，以保持該政策在有效期內，直到其成為下文第3.1(b)節所描述的共識政策。如果在這一年期間，臨時政策或規範未能成為符合下文第3.1(b)節標準的共識政策，則登記機構將不再需要遵守或實施該臨時政策或規範。
(b) 共識政策.
(i) 在本協議的有效期內，根據本協議的條款，登記運營商將全面遵守並實施截至生效日期的所有共識政策，並根據ICANN的章程，未來可能會開發和採納的共識政策，具體如下。
(ii) "共識政策"是指根據ICANN的章程和正當程序所建立的規範或政策，並涵蓋下列第3.1(b)(iv)節所列的主題。根據ICANN的章程所規定的共識政策的開發過程和程序可能會不時修訂，任何通過這一修訂過程採納的共識政策，並且涵蓋下列第3.1(b)(iv)節所列的主題，將被視為本協議下的共識政策。
(iii) 根據本協議的所有目的，位於https://www.icann.org/consensus-policies的政策將以同樣的方式處理，並具有與"共識政策"相同的效果。
(iv) 共識政策及其開發程序應旨在在各種可能的範疇內，實現互聯網相關利益相關者（包括gTLD運營商）的共識。共識政策應與以下一項或多項相關：(1) 為促進互操作性、安全性和/或互聯網或DNS的穩定性而合理必要的統一或協調解決問題；(2) 提供登記服務的功能性和性能規範（如第3.1(d)(iii)節所定義）；(3) TLD的登記數據庫的安全性和穩定性；(4) 實施與登記運營或登記商相關的共識政策所合理必要的登記政策；或(5) 當前與域名註冊有關的爭議解決（與這些域名的使用相對）。前述類別的問題不包括但不限於:
2
(A) 在頂級域名(TLD)中分配註冊名稱的原則（例如，先到先得、及時續約、到期後的保留期）；
(B) 禁止註冊機構或註冊商囤積或投機於域名；
(C) 在頂級域名中保留不可以最初註冊或因合理原因不能續約的註冊名稱，這些原因與(a) 避免用戶之間的混淆或誤導，(b) 知識產權，或(c) DNS或互聯網的技術管理有關（例如，建立名稱的保留以防止註冊）；
(D) 維護及存取有關域名註冊的準確及最新資訊；
(E) 避免因註冊機構或註冊商停止或終止運營而導致域名註冊中斷的程序，包括對於受此停止或終止影響的TLD中註冊域名的責任分配程序；以及
(F) 解決有關特定當事方是否可以註冊或維持特定域名註冊的爭議。
(v) 除了對共識政策的其他限制外，他們不得：
(A) 規定或限制註冊服務的價格；
(B) 修改擬議登記服務的考量標準，包括下面所述的安全性和穩定性的定義，以及ICANN所適用的標準；
(C) 修改本協議的續約或終止條款或條件；
(D) 修改ICANN在第3.2(a)、(b)和(c)條款下對登記運營商的義務；
(E) 修改對共識政策或臨時規範或政策的限制；
(F) 修改登記服務的定義；
(G) 修改下面第7.2和7.3條款的條件；以及
(H) 修改根據本協議第3.1(d)條款實施的服務（除非基於安全性和穩定性的迫切需要，有令人信服和正當的理由）。
(vi) 登記運營商在收到共識政策或臨時規範或政策建立通知後，應被提供合理的時間來遵守該政策或規範，考慮到相關的緊急情況。
在以下第3.1(d)(iii)節所定義的登記服務與根據此第3.1(b)節制定的共識政策或根據上述第3.1(a)(i)節所制定的任何臨時規範或政策之間發生衝突的情況下，共識政策或臨時規範或政策應優先適用，而不論本協議中包含的任何其他條款。
(c) 登記數據的處理.
3
(i) 數據擔保. 登記機構應自費為登記機構編纂的登記數據建立數據擔保或鏡像網站政策。本協議中所使用的登記數據應指以下內容：(1) 所有登記商贊助的域名數據，包括域名、每個名稱伺服器的伺服器名稱、登記商ID、更新日期、創建日期、到期日期、狀態信息，以及DNSSEC委託簽名者（"DS"）數據；(2) 所有登記商贊助的名稱伺服器數據，包括伺服器名稱、每個IP地址、登記商ID、更新日期、創建日期、到期日期和狀態信息；(3) 贊助已登記域名和名稱伺服器的登記商數據，包括登記商ID、登記商地址、登記商電話號碼、登記商電子郵件地址、whois伺服器（如果由登記商提供，則在2025年1月28日後將繼續提供）、推薦的URL、更新日期，以及所有登記商的管理、計費和技術聯絡人的姓名、電話號碼和電子郵件地址；(4) 登記機構從登記商收集的域名註冊者數據，作為註冊域名的一部分或隨後獲得的數據。擔保代理人或鏡像網站管理者及其義務應由ICANN和登記機構在商業上合理的標準下達成一致，並且在技術上和實際上足夠，允許繼任的登記運營商承擔TLD的管理。登記機構應遵守附錄1（數據擔保規範）中所列的登記數據擔保規範，雙方將遵守大致符合附錄2（擔保協議（模板格式））的執行擔保協議。
(ii) 個人數據. 登記運營商應通知為該TLD在登記處贊助註冊的登記機構，收集登記機構提交給登記運營商的個人數據（如以下定義）之目的、該等個人數據的預定接收者（或接收者類別）及訪問和更正該等個人數據的機制。登記運營商應採取合理步驟保護個人數據，以防止其遺失、濫用、未經授權的披露、更改或銷毀。登記運營商不得以與通知中提供的方式不相容的方式使用或授權使用個人數據。 “個人數據”指的是任何已識別或可識別的自然人的所有數據。
(iii) 批量區域文件訪問. 登記運營商將根據附錄3（區域文件訪問）的條款向第三方和ICANN提供區域文件的批量訪問。
(iv) 每月報告. 在每個日曆月結束後的二十（20）個日曆天內，登記運營商應編製並向ICANN提供報告，提供附錄4（登記運營商每月報告的格式和內容）中規定的數據及格式。
(v) 註冊數據目錄服務. 登記運營商應按照附錄5A（註冊數據出版服務規範）及附錄50億元（註冊數據訪問協議服務規範）提供與所營運的頂級域名類型相關的註冊數據（例如，“厚”或“薄”登記模型）。自生效日起，該TLD為“薄”登記模型。
(vi) [保留]
(vii) 公共利益承諾. 登記運營商應遵守附錄11（公共利益承諾）中列出的公共利益承諾。
(d) 登記運營.
4
(i) 註冊限制. 登記運營商應保留並不註冊附錄6所附的保留TLD字符串列表上的任何TLD字符串。
(ii) 功能和性能規範. TLD的運行功能和性能規範應如附錄7（功能和性能規範）、附錄50億（服務水平要求）第3節和附錄50億（無干擾）第4.5節中所述，並且應涵蓋但不限於DNS服務；共享註冊系統的運行；RDDS；和名稱伺服器操作。登記運營商應保留技術和操作記錄，以證明遵守這些規範，至少保留一年。
(iii) 登記服務. 根據本協議，登記服務定義為以下幾項： (a) 同時具備以下條件的服務：(i) 執行登記處的運營，對於以下任務至關重要：接收來自登記商有關域名和名稱伺服器的註冊數據；向登記商提供有關頂級域的區域伺服器的狀態信息；發佈頂級域區域文件；運營登記區域伺服器；以及根據本協議要求發佈有關頂級域內域名伺服器註冊的聯絡及其他信息；(ii) 自2006年3月31日起由登記運營商為.com登記所提供的服務；(b) 登記運營商因建立共識政策（如上述第3.1(b)條所定義）而需提供的其他產品或服務；(c) 只有登記運營商因其被指定為登記運營商而能夠提供的任何其他產品或服務；以及(d) 任何在上述(a)、(b)或(c)範疇內對登記服務的重大變更。僅有在上述(a)和(b)中定義的登記服務受限於下述第7.3條的最高價格規定。
(iv) 對擬議登記服務的考慮流程. 在登記運營商書面通知ICANN其可能對前述段落內的登記服務進行變更後：
(A) ICANN將有15個日曆天的時間進行"初步判定"，以確定登記服務是否需要ICANN進一步考慮，因為它合理地認為該登記服務：(i) 可能引發重大安全或穩定性問題，或(ii) 可能引發重大競爭問題。
(B) 登記運營商必須在通知ICANN時提供足夠的信息，以使其能夠實施擬議的登記服務，從而使ICANN能夠做出明智的"初步判定"。登記運營商提供的並標記為"保密"的信息將被ICANN視為機密信息。登記運營商不會指定描述擬議登記服務目的及對DNS用戶影響所需的"保密"信息。
(C) ICANN可能在初步判定期間（來自受到保密協議約束的實體或個人）尋求專家建議，以針對登記服務的競爭、安全或穩定性影響做出其「初步判定」。在ICANN決定向任何此類專家披露機密信息的範圍內，將會通知登記運營商專家的身份和其打算傳達的信息。
(D) 如果ICANN在15個日曆日的「初步判定」期間確定所提議的登記服務未造成重大安全或穩定性（如下面所定義）或競爭問題，登記運營商可在此判定後自由部署該服務。
5
(E) 如果ICANN在15個日曆日的「初步判定」期間合理地確定登記服務可能引發重大競爭問題，ICANN應在做出判定後的五個工作日內，或在該15天期間結束後的兩個工作日內（以較早者為準），將該問題提交給具有管轄權的相關政府競爭機構，並通知登記運營商。任何此類轉介通信應在傳送當日發布在ICANN網站上。經過該轉介後，ICANN將不再負擔進一步責任，登記運營商對ICANN就登記服務的任何競爭問題亦不再有進一步義務。如果發生該轉介，登記運營商不得在轉介後的45個日曆日內部署該登記服務，除非獲得所轉介政府競爭機構的提前批准。
(F) 如果ICANN在15個日曆日的「初步判定」期間合理地確定所提議的登記服務可能引發重大穩定性或安全性問題（如下面所定義），ICANN將在做出判定後的五個工作日內，或在該15天期滿後的兩個工作日內（以較早者為準），將該提案提交給專家常設小組（如下面所定義），並同時邀請公眾對該提案進行意見反饋。專家常設小組應在轉介後的45個日曆日內準備有關所提議登記服務對安全性或穩定性影響的書面報告（如下面所定義），該報告（以及任何公眾意見的摘要）將轉交給ICANN董事會。報告應提出專家常設小組的意見，包括但不限於小組依據其結論所依賴的具體分析、理由及信息的詳細說明，以及對ICANN員工轉介中包含的具體問題的回答。在ICANN向專家常設小組轉介後，登記運營商可以提交有關登記服務對安全性或穩定性可能影響的附加信息或分析。
(G) 針對提議的登記服務進行評估後，常設小組將報告該登記服務對安全性或穩定性的影響的可能性和重要性，包括提議的登記服務是否對下文定義的安全性或穩定性造成合理風險的重大不利影響：
安全: 根據本協議，提議的登記服務對安全性的影響應指 (1) 登記數據的未經授權披露、變更、插入或銷毀，或 (2) 根據所有適用標準操作的系統未經授權訪問或披露互聯網上的信息或資源。
穩定性: 根據本協議，提議的登記服務對穩定性的影響應指該服務 (1) 不符合由建立良好、被認可且具權威性的標準機構發布的適用相關標準，如由IETF贊助的相應標準追蹤或最佳目前實踐RFC，或 (2) 創造出一種不利於通過、響應時間、一致性或對互聯網伺服器或終端系統的回應連貫性、這些系統依循已被建立良好、被認可且具權威性的標準機構所發布的適用相關標準，這些標準可能涉及到登記運營商的委派信息或供應服務。
(H) 在收到常設小組的報告後，該報告將會被公布（經過與登記運營商協商後進行適當的保密篩選），並可供公眾
6
評論，ICANN董事會將有30天的日曆時間來做出決定。如果ICANN董事會合理地認為提議的登記服務對穩定性或安全性造成合理風險的重大不利影響，則登記運營商將不會提供該提議的登記服務。常設小組的未經篩選版本將在報告發布時提供給登記運營商。登記運營商可以對常設小組的報告作出回應，或者向ICANN董事會提交有關該登記服務對安全性或穩定性可能影響的其他信息或分析。
(I) The Standing Panel shall consist of a total of 20 persons expert in the design, management and implementation of the complex systems and standards-protocols utilized in the Internet infrastructure and DNS (the "Standing Panel"). The members of the Standing Panel will be selected by its Chair. The Chair of the Standing Panel will be a person who is agreeable to both ICANN and the registry constituency of the supporting organization then responsible for generic top level domain registry policies. All members of the Standing Panel and the Chair shall execute an agreement requiring that they shall consider the issues before the panel neutrally and according to the definitions of Security and Stability. For each matter referred to the Standing Panel, the Chair shall select no more than five members from the Standing Panel to evaluate the referred matter, none of which shall have an existing competitive, financial, or legal conflict of interest, and with due regard to the particular technical issues raised by the referral.
(e) Fees and Payments. Registry Operator shall pay the Registry-Level Fees to ICANN on a quarterly basis in accordance with Section 7.2 hereof.
(f) Traffic Data. Nothing in this Agreement shall preclude Registry Operator from making commercial use of, or collecting, traffic data regarding domain names or non-existent domain names for purposes such as, without limitation, the determination of the availability and Security and Stability of the Internet, pinpointing specific points of failure, characterizing attacks and misconfigurations, identifying compromised networks and hosts, and promoting the sale of domain names; provided, however, that such use does not disclose domain name registrant, end user information or other Personal Data as defined in Section 3.1(c)(ii) for any purpose not otherwise authorized by this Agreement. In this regard, in the event the TLD registry is a "thick" registry model, the traffic data that may be accessible to and used by Registry Operator shall be limited to the data that would be accessible to a registry operated under a "thin" registry model. The process for the introduction of new Registry Services shall not apply to such traffic data. Nothing contained in this Section 3.1(f) shall be deemed to constitute consent or acquiescence by ICANN to a re-introduction by Registry Operator of the SiteFinder service previously introduced by the Registry Operator on or about September 15, 2003, or the introduction of any other service employing a universal wildcard function, except that this sentence shall not prohibit the provision of nameservice or any other non-registry service for a domain or zone used for other than registration services to unaffiliated third parties by a single entity (including its affiliates) for domain names registered through an ICANN-accredited registrar. To the extent that traffic data subject to this provision is made available, access shall be on terms that are non-discriminatory.
(g) 安全與穩定性檢討. 每年兩次，登記機構應與ICANN的執行團隊及董事會主席進行討論，針對影響登記處、安全性和/或穩定性、DNS或互聯網的趨勢，根據ICANN的執行團隊和董事會主席簽署的保密協議進行討論。
7
(h) 業務延續性. 為維護和提升TLD及互聯網的安全性、穩定性和韌性，登記機構和ICANN同意，雙方的內部專家將針對關鍵的登記功能、操作和安全性進行會議，討論如何：(i) 雙方可在各種情境下處理業務延續性，包括觸發任何業務延續機制的適當標準；及 (ii) 減輕來自此類業務延續情境對TLD及互聯網的風險。此類討論將每月在雙方協商同意的時間和地點進行，並應至少在生效日起的180天內舉行，除非雙方書面同意較短的時間（可通過電子郵件）。在本條所述的討論結束後，雙方將竭盡商業上的合理努力，以確定對TLD合理適宜的任何業務延續實踐的實施方案。雙方同意，此類實施可能包括雙方書面協商同意的本協議修正。
第3.2節 ICANN的承諾. ICANN承諾並與登記機構達成如下協議：
(a) 開放和透明根據ICANN所表達的使命和核心價值觀，ICANN將以開放和透明的方式運作。
(b) 公平對待ICANN不得任意、不合理或不公平地應用標準、政策、程序或實踐，也不得單獨對登記機構採取不平等待遇，除非有充分且合理的理由。
(c) TLD區域伺服器在ICANN獲得授權設定與權威根伺服器系統相關的政策的情況下，ICANN將確保(i)權威根將指向登記機構指定的TLD區域伺服器，並保持整個協議的有效期；(ii)登記機構提交給ICANN的任何TLD區域伺服器指派的變更將在提交後七天內由ICANN實施。
(d) 名稱伺服器變更登記機構可以要求變更登記TLD的名稱伺服器委派。任何此類請求必須以ICANN不時指定的格式提出，並滿足技術要求。ICANN將以商業上合理的努力，在提交後七個日曆日內在權威根伺服器系統中實施此類請求。
(e) 根區信息發布. ICANN發佈的根區聯絡資訊將包括登記機構及其行政和技術聯絡人。對於修改登記機構聯絡資訊的任何請求，必須按照ICANN不時指定的格式提出。
第3.3節 合作事項. 雙方同意互相合作，並在必要時共享數據，以達成本協議的條款。
第3.4節 合約和操作合規審計.
(a) ICANN可能不時（不超過每個日曆季度一次）進行或委託第三方進行合約合規審計，以評估登記機構對本協議第二條中的陳述和保證以及第三條中的契約的遵循情況。這些審計將根據評估合規的目的進行定制，ICANN將(i)提前合理通知任何此類審計，該通知應合理詳盡地指明所請求的文件、數據和其他信息的類別，
8
(ii) 盡商業上的合理努力，以不會不合理地干擾登記機構的運營的方式進行此類審計。在該審計的一部分中，根據ICANN的要求，登記機構應及時提供所有相關的文件、數據和任何其他必要信息，以證明登記機構對本協議的合規情況。在不少於五（5）個工作日的通知下（除非登記機構另有協議），ICANN可以作為任何合約合規審計的一部分，在正常的工作時間內進行實地訪問，以評估登記機構對第3.1節契約的遵循情況。
(b) 依據第3.4(a)條進行的任何審計將由ICANN負擔費用，除非(i)該審計涉及登記運營商對第3.1(c)(iv)條的合規性，且該審計揭示登記運營商提供的數據存在重大差異，或(ii)該審計與登記運營商根據本協議支付的費用超過5%且對ICANN造成損害的差異有關。在上述(i)或(ii)的任一情況下，登記運營商應向ICANN償還與該審計相關的所有合理成本和費用，且該償還將與下一次到期的登記層級費用支付一起支付，該費用付款是在該審計的成本報告發送之後。
第四條 協議的期限
第4.1节 條款本協議的有效期限自生效日期開始，並持續至2030年11月30日（「初步登記協議期限」），如根據第4.2條（續約）延長（每個均為「續約登記協議期限」）。初步登記協議期限和所有續約登記協議期限合在一起構成（「條款”).
第4.2節 續保. This Agreement shall be renewed upon the expiration of the Initial Registry Agreement Term set forth in Section 4.1 above and each Renewal Registry Agreement Term, unless the following has occurred: (i) following notice of breach to Registry Operator in accordance with Section 6.1 and failure to cure such breach within the time period prescribed in Section 6.1, an arbitrator or court has determined that Registry Operator has been in fundamental and material breach of Registry Operator's obligations set forth in Sections 3.1(a), (b), (d) or (e); Section 5.2 or Section 7.3 and (ii) following the final decision of such arbitrator or court, Registry Operator has failed to comply within ten days with the decision of the arbitrator or court, or within such other time period as may be prescribed by the arbitrator or court. Upon renewal, in the event that the terms of this Agreement are not similar to the terms generally in effect in the Registry Agreements of the 5 largest gTLDs (determined by the number of domain name registrations under management at the time of renewal), renewal shall be upon terms reasonably necessary to render the terms of this Agreement similar to such terms in the Registry Agreements for those other gTLDs. The preceding sentence, however, shall not apply to the terms of this Agreement regarding the price of Registry Services; the standards for the consideration of proposed Registry Services, including the definitions of Security and Stability and the standards applied by ICANN in the consideration process; the terms or conditions for the renewal or termination of this Agreement; ICANN's obligations to Registry Operator under Section 3.2 (a), (b), and (c); the limitations on Consensus Policies or Temporary Specifications or Policies; the definition of Registry Services; or the terms of Section 7.3.
第4.3節 Failure to Perform in Good Faith. In the event Registry Operator shall have been repeatedly and willfully in fundamental and material breach of Registry Operator's obligations set forth in Sections 3.1(a), (b), (d) or (e); Section 5.2 or Section 7.3, and arbitrators in accordance with Section 5.1(b) of this Agreement repeatedly have found Registry Operator to have been in
9
對本協議的基本和重大違約，包括至少三項獨立的獎項，則仲裁員應根據情況授予他們認為適當的懲罰性、示範性或其他損害賠償。
第五條 處理爭議
第5.1條 爭議的解決.
(a) 合作協商. 若註冊機構與ICANN因本協議產生或與之相關的分歧，任何一方可以通知另一方來啟動本第V條的爭議解決條款。前提是，在任何一方可以根據下面第5.1(b)條啟動仲裁之前，ICANN和註冊機構必須按照本第5.1(a)條的規定嘗試通過合作協商來解決爭議。如果任一方向另一方提供書面通知，要求根據本第5.1(a)條進行合作協商，則每一方需在根據本條第8.8條規定視為收到該書面通知後的七個日曆日內，指定一名高級執行官作為該第5.1(a)條的代表，擁有全權代表該方進行爭議解決。指定的代表應在指定後兩個工作日內通過電話或親自會議，嘗試解決爭議。如果他們在該電話會議或會面期間未能解決爭議，則應在初次電話會議或會面後的七個日曆日內，在ICANN合理指定的地點進一步會面，屆時雙方應嘗試達成明確的解決方案。本第5.1(a)條所列的時間表和過程可以根據任何爭議進行修改，但只有在雙方事先書面同意修訂時間表或過程的情況下。該段落範圍內的和解通訊在雙方之間的任何仲裁或訴訟中均不可接受。
(b) 仲裁. 根據本協議產生或與之相關的爭議，包括特定履行的請求，應通過根據本第5.1(b)條的規定進行的具有約束力的仲裁來解決，仲裁將根據國際商會國際仲裁法庭的規則進行（"ICC"）。仲裁將以英語進行，並僅在加利福尼亞州洛杉磯縣進行，前提是未能根據上述第5.1(a)條的合作協商討論解決爭議。仲裁員將有三名：每一方選擇一名仲裁員，如兩位仲裁員未能就第三名仲裁員達成共識，則第三名仲裁員將由ICC選擇。在仲裁中獲勝的一方有權要求回收其費用和合理的律師費，仲裁員應將其列入裁決中。任何一方若希望確認或撤銷根據本第5.1(b)條發出的仲裁裁決，僅可根據適用的仲裁法規進行。在涉及ICANN的任何訴訟中，有關本協議的管轄權和排他性的訴訟地點應位於加利福尼亞州洛杉磯縣的法院；但雙方也有權在任何有管轄權的法院執行該法院的判決。為了幫助仲裁和/或在仲裁進行期間維護雙方的權利，雙方有權向仲裁小組或法院申請暫時禁制令或救濟，這不應被視為放棄本仲裁協議。
以上第5.2節所列之買受人陳述及保證應於交割日時完全準確無誤。 具體履行登記機構與ICANN同意，如果本協議的任何條款未按其具體條款執行，可能會造成無法彌補的損害。因此，雙方同意各自有權向仲裁人尋求
10
本協議條款的具體履行（除了每一方有權獲得的任何其他補救措施）。
5.3 節 責任限制ICANN因違反本協議而承擔的總貨幣責任不得超過根據本協議第7.2條在前十二個月內由登記機構支付給ICANN的登記級別費用的金額。登記機構因違反本協議而對ICANN承擔的總貨幣責任應限制於在前十二個月內根據本協議應付給ICANN的費用和金錢制裁（如有）。在任何情況下，任何一方均不對因本協議或履行或不履行本協議中承擔的義務而引起的特別、間接、附帶、懲罰性、示範性或衍生損害負責，除非根據本協議第4.3條的規定。除非本協議另有明確規定，登記機構不對其自身、其員工或其代理人所提供的服務或其工作所取得的結果作出任何明示或暗示的保證，包括但不限於任何暗示的可銷售性、不侵犯他人權利或適合特定目的的保證。
第六條 終止條款
第6.1節。 由ICANN終止ICANN僅可在以下情況下終止本協議： (i) 登記機構未能在ICANN發出書面通知後的三十個日曆日內，對登記機構在第3.1條(a)、(b)、(d)或(e)；第5.2條或第7.3條中所列的義務所構成的任何根本性和重大違約進行補救，該通知應具體包含對所謂違約的詳情；及 (ii) (a) 仲裁員或法院最終認定登記機構存在或曾存在根本性和重大違約且未能在規定的時間內補救該違約，和 (b) 根據該仲裁員或法院的決定，登記機構未能遵守該仲裁員或法院的決定。
6.2 節 破產如果登記機構自願或非自願地處於破產程序，則本協議將自動終止。
6.3 節 協議終止後的登記機構過渡. 根據第6.1和6.2條款的規定，任何終止本協議的情況下，雙方同意協力合作，以促進和實施根據本第6.3條款轉移TLD的登記管理。登記管理人同意向ICANN或可能被指定為TLD的任何繼任登記機構提供有關該TLD登記運作的必要數據，以維持運作，這些數據是根據本協議第3.1(c)(i)條款進行資料保管的。
第6.4節 數據權利. 登記管理人無權主張對登記數據的任何知識產權。在第3.1(c)(i)條款所列的情況下，若登記數據從保管中釋放，登記管理人在數據中擁有的權利（如有）將自動以非獨佔、不可撤銷、免版稅、已支付的方式授權給ICANN或ICANN書面指定的任何方。
段 不予報銷. 登記管理人根據本協議所做的任何或所有支出、資本投資或其他投資應由登記管理人自負其責
11
風險，ICANN對於任何該等費用、資本支出或投資均無補償的義務。登記管理人不需要就登記費用於本協議的終止或到期的生效日前支付給繼任登記管理人，除非登記的過渡延遲是由於登記管理人的行為所致。
第七條 特別條款
第7.1節 登記處-登記商協議.
(a) 登記服務的存取登記運營商應向所有ICANN認可的登記商提供登記服務的存取，包括共享登記系統，並須遵循附錄8所附的登記處-登記商協議的條款。根據第7.1(d)條款，登記運營商在簽署登記處-登記商協議後，將向所有ICANN認可的登記商提供操作性存取登記服務，包括TLD的共享登記系統，只要登記商遵守該協議。此種不歧視性存取應包括但不限於以下內容：
(i) 所有登記商（包括任何與登記運營商相關的登記商，如有）可以透過Internet使用相同的最大IP地址數量和SSL證書驗證，連接到TLD的共享登記系統網關；
(ii) 登記運營商已使當前版本的登記商工具包軟件可供所有登記商使用，並將任何更新以相同的時間表提供給所有登記商；
(iii) 所有登記商通過電話、電子郵件和登記運營商的網站對客戶支持人員擁有相同級別的存取。
(iv) 所有註冊商皆具相同級別的訪問權限，以解決註冊處/註冊商或註冊商/註冊商之間的爭議及技術和/或行政客戶服務問題；
(v) 所有註冊商均可訪問由註冊運營商產生的數據，以調整其從註冊運營商的網絡和ftp伺服器上進行的註冊活動；
(vi) 所有註冊商可以使用註冊運營商提供給所有註冊商的相同註冊商工具，執行基本的自動化註冊商帳戶管理功能；以及
(vii) 共享註冊系統不包括任何將註冊商在功能上區分的算法或協議，以免提供歧視性的訪問，包括數據庫訪問、系統優先級和整體性能。
該註冊-註冊商協議可由註冊運營商不時修訂，但所有此類修訂必須事先獲得ICANN的批准。
(b) 註冊運營商不得擔任自身的註冊商. 註冊運營商不得擔任與該頂級域名（TLD）相關的註冊商。這不妨礙註冊運營商通過向ICANN認可的註冊商提出請求，自行在該頂級域名內註冊名稱。此外，在對該頂級域名或互聯網安全與穩定構成即將威脅的情況下，該條款不妨礙註冊運營商為保護該頂級域名或互聯網的安全與穩定，暫時禁止註冊一個或多個名稱；前提是，註冊運營商在采取該行動後，應在可行的最短時間內但不遲於3個工作日內，向ICANN提供該行動的書面通知，該通知應列出所有受影響的名稱，並說明
12
這些名稱將不再可供註冊的預期時間長度，並解釋為何註冊運營商採取此行動。此類通知的內容應在法律允許的範圍內被視為保密。如果ICANN不同意該行動，它將指示註冊運營商釋放這些名稱，註冊運營商應在收到ICANN的書面指示後立即釋放這些名稱。
(c) 對於註冊機構的所有權或控制權的獲取限制註冊機構不得直接或間接地獲得對任何ICANN認可的頂級域註冊機構的控制權或超過十五%的所有權。
(d) 合規行動註冊機構承認，所有ICANN認可的註冊機構必須與ICANN簽訂註冊機構認證協議（"RAA"），而ICANN可能會根據緊急情況或根據RAA的條款採取某些合規行動，包括暫停或終止註冊機構的認證或暫停註冊機構創建新註冊名稱或啟動註冊名稱的入站轉移的能力。ICANN可能要求註冊機構採取具體行動，以符合ICANN根據RAA條款的權力： (i) 暫停或終止註冊機構創建新註冊名稱的能力或 (ii) 將註冊名稱轉移給ICANN指定的註冊機構。
第7.2節 需支付給ICANN的費用.
(a) 註冊層級費用註冊機構應向ICANN支付一項註冊層級費用，該費用等於(i) 每個日曆季度結束後20天內支付的“註冊固定費用”為6,250美元（即在1月20日、4月20日、7月20日和10月20日），(ii) 註冊層級交易費（如下文定義），(iii) 同步交易費（如下文定義）和 (iv) 可變註冊層級費用（如下第7.2(b)節定義）（統稱為子條款(i)-(iv)，“註冊層級費用”）。註冊機構應根據每個日曆季度結束後20天內的計算，按年度增量支付“註冊層級交易費”，該費用等於所有初始或續期域名註冊（在一個或多個層級，包括與從一個ICANN認可的註冊機構轉移到另一個的續期有關的續期）在適用的日曆季度中的數量乘以0.25美元。註冊機構應在每個日曆季度結束後的20天內向ICANN指定的賬戶支付註冊層級交易費（即對於結束於12月31日、3月31日、6月30日和9月30日的日曆季度，分別為1月20日、4月20日、7月20日和10月20日）。對於因註冊機構的合併/同步服務（“同步服務”）（參見附錄9（批准的服務））在生效日期後延長註冊期限的每個TLD域名註冊，註冊機構應向ICANN支付額外費用，該費用按0.25美元的金額按比例計算，基於域名註冊超過到期日的延長天數的計算（“同步交易費”）。註冊機構應在同步服務發生的日曆季度結束後的20個日曆日內向ICANN支付同步交易費（即1月20日、4月20日、7月20日和10月20日）。
(b) 變數登記層級費用. 在ICANN未從所有註冊商收取變數認證費的財政季度期間，根據ICANN的書面通知，登記運營商應支付ICANN變數登記層級費用（以下稱「變數登記層級費用」）。該費用將由ICANN按季度計算並開具發票，並應在收到該ICANN財政年度第一季度（7月1日至9月30日）發票金額後的六十（60）個日曆天內由登記運營商支付，以及在收到剩餘季度每期發票金額後的二十（20）個日曆天內支付。
13
登記運營商將從與登記運營商簽訂登記-註冊商協議的註冊商那裡開具並收取費用。變數登記層級費用將由兩個組成部分組成；每個組成部分將由ICANN根據每個註冊商計算：
(i)變數登記層級費用的交易組成部分應由ICANN根據ICANN董事會為每個ICANN財政年度通過的預算規定，但不應超過0.25美元。
(ii)變數登記層級費用的每註冊商組成部分應由ICANN根據ICANN董事會為每個ICANN財政年度通過的預算規定。
(c) 逾期付款的利息. 根據第7.2條，對於任何逾期十天或更長時間的付款，登記運營商應按每月1.5%的利率支付逾期付款的利息，或如果低於此，則支付適用法律允許的最高利率。
(d) 對費用的調整儘管本協議第7.2(a)或7.2(b)條中對登記機構支付給ICANN的登記級費用金額有限制，自每年12月1日起，在本協議有效期內，根據ICANN的酌情權，第7.2(a)和第7.2(b)條中所列的當前費用可以根據以下百分比變化進行調整：即(i)由美國勞工部勞工統計局或其任何繼任指數（「CPI」）發布的全美城市平均消費者物價指數（1982-1984 = 100）於適用年份開始前一個月的數值變化百分比，與(ii)於前一個年度開始前一個月的CPI進行比較。如有任何此類增加，ICANN應通知登記機構，具體說明調整金額。本第7.2(d)條下的任何費用調整應在ICANN向登記機構送達此類費用調整通知後至少三十（30）天的第一個日曆季度的第一天生效。
(e) 費用調整實踐ICANN同意，如果它根據第7.2(d)條行使其調整登記級費用的權利，ICANN還應根據多個其他登記協議以不針對特定登記機構的方式行使其權利。
(f) ICANN和登記機構特此同意，如果ICANN在2024年11月1日之後且在生效日期之前向其他登記機構發送費用調整通知，ICANN可以同時向登記機構發送此類費用調整通知，在這種情況下，第7.2(d)條的條款應被視為在該通知發送時已經適用。
第7.3章 域名註冊和登記服務的定價.
(a) 範圍本第7.3條規定適用的登記服務為：
(i) 上述第3.1(d)(iii)(a)節中定義的登記服務，及
(ii) 由於建立共識政策（如上述第3.1(b)節中定義），登記運營商需要在上述第3.1(d)(iii)(b)節的範圍內提供的其他產品或服務：
14
(1) 實施對登記服務（如上述第3.1(d)(iii)(a)節中定義）核心功能或性能規範的變更；或
(2) 為促進以下事項而合理必要的： (A) 互聯網或DNS的安全性和/或穩定性； (B) 頂級域名的登記數據庫的安全性和穩定性；或 (C) 關於域名註冊的爭議解決（而非這些域名的使用）。
本條款中所載內容不得解釋為將本節7.3的條款適用於本協議附錄9中列舉的服務。
(b) 禁止綁定登記運營商不得要求作為本協議第7.3節所述登記服務提供或使用的條件，包括但不限於第7.1節和附錄10的條款，要求該等服務的購買者購買任何其他產品或服務或拒絕購買任何其他產品或服務。儘管可能有其他報價包括所有或任何部分的登記服務的任何價格，登記運營商應向所有ICANN認可的註冊商提供本節7.3所述所有登記服務的組合，該組合的總價格不得高於根據第7.3(d)節計算的最高價格，並且須符合第7.3節的所有要求。
(c) 登記服務的價格本節7.3所涉及的所有登記服務的價格應為登記運營商對每年新增和續期域名註冊以及每次從一個ICANN認可的註冊商轉移域名註冊所收取的金額，該金額不得超過最高價格。
(d) 最高價格本節7.3所涉及的登記服務的最高價格如下：
(i) 根據第7.3(d)(ii)和第7.3(d)(iii)節的規定，登記服務的最高價格應為美金10.26元；
(ii) 登記運營商有權將最高價格提高至(A) 前一定價年度的最高價格（如第7.3(d)(iii)節所定義），乘以1.07，或(B) 前一個定價年度登記運營商收取的登記服務最高價格，乘以1.07，並且在每六年期間的最後四個定價年度中，對(A)或(B)進行調整，首個六年期間自2018年10月26日開始；
(iii) 登記運營商有權將最高價格提高至足以涵蓋由於施加任何新的共識政策或由於對DNS安全或穩定的攻擊或攻擊威脅所產生的記錄下來的特別支出而產生的任何額外增量成本的金額，該金額不得超過(A) 前一個定價年度的最高價格，乘以1.07，或(B) 前一個定價年度登記運營商收取的登記服務最高價格，乘以1.07，前提是，登記運營商只能在未對第7.3(d)(ii)節所述的登記服務增加最高價格的定價年度內，根據本節7.3(d)(iii)的規定，對共識政策或記錄下來的特別支出提高最高價格。根據第7.3節的規定，“定價年度”應指從10月26日到10月25日的期間。
15
(e) 無價格歧視. 登記機構在本第7.3條款下應對所有ICANN認證的註冊商收取相同的登記服務價格，最高不超過最高價格（前提是如果所有ICANN認證的註冊商都有相同的機會符合這些折扣及市場支持和獎勵計劃，則可以提供量販折扣及市場支持和獎勵計劃）。
(f) 域名註冊價格調整. 登記機構應在任何新註冊和續訂域名註冊的價格提高前至少提前六個月通知，並在將域名註冊從一個ICANN認證的註冊商轉移到另一個ICANN認證的註冊商時，也應提前通知，並應繼續提供長達十年的新註冊和續訂域名註冊，其價格固定在此優惠被接受時的有效價格。登記機構不需要通知根據第7.2(b)條款所規定的可變登記層級費用的實施。
(g) 最高價格不包括ICANN可變登記層級費用. 最高價格不包括，也不應從包含上述第7.2(b)條件所規定的全部或任何部分的ICANN可變登記層級費用計算，以及其他任何每個名稱新的和續訂域名註冊的費用，及將域名註冊從一個ICANN認證的註冊商轉移到另一個的費用。
第八條 其他
第8.1節 對ICANN的賠償責任.
(a) 注册机构应赔偿、辩护并使ICANN（包括其董事、高级职员、员工和代理人）免受任何和所有第三方的索赔、损害、责任、成本和费用，包括合理的法律费用和开支，因以下原因引起或与之相关：(a) ICANN 在将顶级域名委托给注册机构或签署本协议时依赖注册机构在其顶级域名申请中提供的信息；(b) 注册机构建立或运营顶级域名的注册处；(c) 注册机构提供注册服务；(d) 注册机构收集或处理个人数据；(e) 任何关于在顶级域名注册处域内注册域名的争议；以及 (f) 注册机构在运营顶级域名注册处时的职责和义务；前提是，注册机构不应承担赔偿、辩护或使ICANN免受损害的责任，前提条件是索赔、损害、责任、成本或费用是因ICANN违反本协议中任何义务或ICANN的任何故意不当行为而产生。为避免疑义，本第8.1节中的任何内容均不应被视为要求注册机构报销或以其他方式赔偿ICANN与本协议的谈判或执行相关的费用，或与各方根据本协议的各自义务的监督或管理相关的费用。此外，本节不适用于与各方之间的任何诉讼或仲裁相关的律师费请求。
(b) 对于ICANN提出的赔偿索赔，其中多个注册机构（包括注册机构）已参与导致该索赔的行为或不作为，注册机构对ICANN的累计赔偿责任应限于ICANN总索赔的一个百分比，该百分比是通过将注册机构在顶级域名下的注册总域名数量（该注册名的计算应与本协议第7.2节的规定一致，适用于任何相关的季度）除以所有顶级域名的注册总域名数量，该顶级域名的注册机构是
16
從事相同的行為或不作為而產生此類索賠。為了避免疑慮，若登記機構從事相同的行為或不作為而導致上述索賠，但該等登記機構對ICANN並不具備上述8.1(a)條款所設定的相同或類似的賠償責任，則此類登記機構所管理的域名數量仍應納入前述句子的計算中。
第8.2節 賠償程序如果ICANN收到任何根據上述第8.1節賠償的第三方索賠通知，ICANN應立即通知登記機構該等索賠。登記機構有權在及時向ICANN發送通知的情況下，選擇立即控制該索賠的辯護和調查，並聘用和雇用對賠償方合理可接受的律師來處理和辯護該索賠，但應由賠償方獨自承擔所有費用和支出，前提是無論如何，ICANN有權以其自行費用和支出控制與ICANN政策或行為的有效性或解釋相關的訴訟。ICANN應在其自身費用下，在合理範圍內配合登記機構及其律師進行該等索賠的調查、審判和辯護，以及由此產生的任何上訴；但賠償方可自行承擔費用，通過其律師或以其他方式參與該等索賠的調查、審判和辯護以及由此產生的任何上訴。對於涉及影響ICANN的補救措施的索賠和解，除非獲得ICANN的同意，否則不得進行。若登記機構未按照本節完全控制有關索賠的辯護，則登記機構可在其獨自費用下參與該辯護，ICANN則有權以其認為合適的方式對該索賠進行辯護，並由登記機構承擔費用和支出。
第8.3節 無抵消根據本協議的所有付款必須在本協議的期間內及時進行，儘管存在註冊機構與ICANN之間的任何爭議（無論是金額上的還是其他方面的）。
第8.4節 使用ICANN名稱和標誌ICANN授予註冊機構一項非專屬的免版稅許可，聲明其被ICANN指定為該登記TLD的註冊機構，並使用ICANN指定的標誌以表明註冊機構是一個ICANN指定的登記機構。該許可不得由註冊機構轉讓或再授權。
第8.5節 轉讓和分包本協議的任何轉讓僅在受讓方與另一方書面同意承擔轉讓方在本協議下的義務時生效。此外，任何一方不得在未經另一方事先書面批准的情況下轉讓本協議，該批准不應被不合理地拒絕。儘管有上述規定，ICANN可以在與ICANN的重組或重新設立相關的情況下，將本協議轉讓給組織目的相同或基本相同的其他非營利公司。登記運營商必須通知ICANN任何分包安排，任何對TLD業務部分進行分包的協議必須要求登記運營商遵守本協議下的所有契約、義務和協議。任何技術操作的分包必須規定分包實體成為本協議第3.1(c)(i)條所要求的数据托管協議的一方。
第8.6節 修改和豁免事項對本協議或其任何條款的任何修訂、補充或修改，必須由雙方書面簽署，方可具約束力。任何條款的放棄，必須有簽名的書面文件，方可具約束力，
17
放棄遵守該條款的當事方。對本協議任何條款的放棄或未能執行本協議的任何條款，不應被視為或構成對本協議任何其他條款的放棄，亦不應使任何此類放棄構成持續放棄，除非另有明確規定。
第8.7節 沒有第三方受益人。本協議不應被解釋為使任何非本協議方，包括任何登記機構或註冊名稱持有人，對ICANN或登記運營商有任何義務。
第8.8節。如果本協議的任何條款被認定為無效或無法執行，則應盡可能解釋該條款，以使其可以執行並根據本協議原有條款的基本相同條件完成所預期的交易。如果沒有可行的解釋能夠挽救該條款，則應將其從本協議的其他部分中刪除，而其他部分仍然完整有效，除非刪除的條款對當事方的權利或利益至關重要。在這種情況下，雙方應商業上合理努力，善意地協商替代的、有效和可執行的條款或協議，以最大程度地實現雙方簽署本協議的意圖。 通知、指定及規範根據或與本協議相關的所有通知應以書面形式發送至下述適當方的地址，或通過下述電子郵件發送，除非該方已根據本協議發出郵政或電子郵件地址變更的通知。任何聯絡信息的變更應由該方在該變更發生後30天內通知。根據本協議要求的任何通知應被視為已妥善發出（i）如果是紙本形式，當親自交付或通過快遞服務並確認收件時；或（ii）通過電子郵件，當收件人的郵件伺服器確認收件時。每當本協議指定某一特定信息的URL地址時，登記機構應被視為已收到任何此類信息的通知，當該信息電子張貼在指定的URL時。如果其他通知方式變得可行，例如通過安全網站發送通知，雙方應共同努力在本協議下實施該通知方式。
若寄往ICANN，地址為：
互聯網名稱與編號指派公司
12025 Waterfront Drive, Suite 300
洛杉磯，加州 90094-2536
電話：1-310-301-5800
注意：總統及首席執行官
抄送至：法律顧問
電子郵件：（視情況而定。）
12025 Waterfront Drive, Suite 300
洛杉磯，加州 90094-2536
電話：1-310-301-5800
注意：總統及首席執行官
抄送至：法律顧問
電子郵件：（視情況而定。）
若寄送至登記運營商，地址為：
VeriSign, Inc.
12061 Bluemont Way，
維吉尼亞州雷斯頓 20190
電話：1-703-948-3200
注意：高級副總裁，副總法律顧問
抄送：總法律顧問
電子郵件：（根據需要不時指定）
12061 Bluemont Way，
維吉尼亞州雷斯頓 20190
電話：1-703-948-3200
注意：高級副總裁，副總法律顧問
抄送：總法律顧問
電子郵件：（根據需要不時指定）
第8.9節 語言；日曆天數. 根據本協議所作的通知、指定、決定和規格應為英文。儘管有任何相反的說法，除非明確指定為「工作日」，否則本協議中使用的「天數」一詞應指「日曆天」。
18
第8.10章節 對照合約本協議可以簽署一份或多份副本，每一份均應視為原件，但所有副本共同構成同一份文件。
第8.11節 整體協議本協議一經簽署，即全面修訂並重新表述之前的協議。本協議（包括其附錄，附錄構成協議的一部分）構成當事方之間有關TLD運作的完整協議，並取代所有先前就該主題所達成的協議、理解、談判和討論，無論是口頭還是書面的。如果本協議正文和其附錄中的任何條款之間發生衝突，則以協議正文中的條款為準。
[簽名頁面見下]
19
為證明所言，各方特此授權其正式授權的代表簽署本協議。
網際網路分配名稱和號碼公司
由： /s/ 薩莉·科斯特頓
薩莉·科斯特頓
Interim President and Chief Executive Officer
Interim President and Chief Executive Officer
日期：2024年11月25日
韋瑞信公司
由： /s/ D. 詹姆斯·比佐斯
D. 詹姆斯·比佐斯
執行董事、總裁兼首席執行官
執行董事、總裁兼首席執行官
日期：2024年11月25日
20
.com 註冊協議附錄 1
資料保管規範
註冊運營商將聘請一個獨立實體作為資料保管代理人（“保管代理”），提供與該協議相關的資料保管服務，依據一份大致如附錄 2 所示的協議，該協議可不時修訂，涉及ICANN、註冊運營商和保管代理人。
對於此處所列的時間表、內容、格式和程序的變更，僅可在ICANN和註冊運營商的共同書面同意下進行（任一方不得無理拒絕），或通過制定如協議第3.1(b)節所概述的共識政策。
技術規範
1存入資金將會有兩種類型的存款：全額存款和差異存款。對於這兩種類型，需考慮的登記物件範圍是那些在提供所有批准的登記服務時所需的物件。
1.1“全額存款將包含在登記中截至提交全額存款給保管代理的當天的00:00:00 UTC（協調世界時間）的數據。
1.2“差異存款是指所有未在上一次全額或差異存款中反映的交易數據。每個差異存款將包含自上次存款完成以來的所有數據庫交易，包括每一天的00:00:00 UTC的數據，週一除外。差異存款必須包括以下規定的完整保管記錄，這些記錄自最新的全額或差異存款以來未被包括或更改（即自上次存款以來所有數據的新增、修改或移除）。
2存款時間表登記運營商將按日提交一組保管文件，如下所示：
2.1每週一，必須在23:59 UTC之前向保管代理提交全額存款。
2.2在其他六（6）天中，必須在23:59 UTC之前向保管代理提交全額存款或相應的差額存款。
3保管格式規範.
3.1 存款格式註冊對象，例如域名、聯絡人、名稱伺服器、註冊商等，將根據RFC 8909的描述編譯成一個文件，參見本附錄第9節的參考文獻1及RFC 9022，參見第9節，
21
本附錄的參考文獻2（統稱“DNDE規範”）。DNDE規範將一些元素描述為可選；如果可用，註冊運營商將在存款中包含這些元素。將使用UTF-8字符編碼。
3.2 擴展如果註冊運營商提供需要提交額外數據的額外註冊服務（未包括在上文中），則將根據具體情況定義額外的“擴展架構”來表示該數據。這些“擴展架構”將根據本附錄第9節中的參考文獻2的描述進行規定。與“擴展架構”相關的數據將包含在本附錄第3.1節中描述的存款文件中。ICANN和註冊運營商將共同合作，就這些新對象的數據保管規範達成一致。
4.處理存款文件建議使用壓縮以減少電子數據傳輸時間和存儲容量要求。將使用數據加密以確保登記保管數據的隱私。處理過的檔案將以二進制OpenPGP格式進行壓縮和加密，根據OpenPGP消息格式 - RFC 4880，請參見本附錄的第9節，參考文獻3。可接受的公共密鑰加密算法、對稱密鑰加密算法、哈希和壓縮算法是RFC 4880中列舉的那些，且在OpenPGP IANA註冊中不標記為被棄用，請參見本附錄的第9節，參考文獻4，這些算法也需是免版稅的。對於原始文本格式的數據文件，應遵循的過程是:
1)根據本附錄第9節，參考文獻1，存款的XML檔案必須以第5節中規定的包含檔案命名，但擴展名為xml。
2)數據文件將聚合在一個稱為(1)的tarball文件中，但擴展名為tar。
3)使用tarball文件作為唯一輸入創建一個壓縮和加密的OpenPGP消息。建議的壓縮算法為ZIP，根據RFC 4880。壓縮數據將使用保管代理的公鑰進行加密。根據RFC 4880，公共密鑰加密的建議算法為Elgamal和RSA。對稱密鑰加密的建議算法為TripleDES、AES128和CAST5，根據RFC 4880。
4)如果壓縮和加密後的文件大小超過與保管代理約定的文件大小限制，則可以根據需要將文件拆分。每個拆分文件的每一部分，或整個文件（如果未拆分）在本節中將稱為處理過的文件。
5)將為每個處理過的文件生成數字簽名文件，使用登記操作員的私鑰。數字簽名文件將為二進制OpenPGP格式，根據RFC 4880第9節，參考文獻3，並且不會被壓縮或加密。數字簽名的建議算法為
22
DSA和RSA，根據RFC 4880。數字簽名中哈希的建議算法為SHA256。
6)處理過的檔案和數位簽名檔案將通過安全的電子機制，如SFTP、SCP、HTTPS檔案上傳等，依據托管代理和登記機構之間的協議轉移給托管代理。如果得到ICANN授權，也可以通過實體媒介如CD-ROM、DVD-ROM或USB儲存設備進行非電子方式的交付。
7)托管代理接著將根據本附錄第8節中描述的程序驗證每個（處理過的）轉移數據檔案。
5.檔案命名慣例. 檔案將根據以下慣例命名：{gTLD}_{YYYY-Mm-DD}_{type}_S{#}_R{rev}.{ext}，其中：
5.1 {gTLD}被替換為gTLD名稱；對於IDN-TLD，必須使用ASCII相容形式(A-Label)；
5.2 {YYYY-Mm-DD}由與所用時間作為交易的時間水印相對應的日期替換；即對於相對應於2009-08-02T00:00Z的完整存檔，將使用字符串“2009-08-02”；
5.3 {type}被替換為：
1)“full”，如果數據代表完整存檔；
2)「diff」，如果數據代表差異存款；
3)「thin」，如果數據代表大宗登記數據訪問文件，如附錄5A第5.1節所規定；
4)「thick-{gurid}」，如果數據代表來自特定登記機構的登記數據，如附錄5A第5.2節所定義。{gurid}元素必須替換為與數據相關的IANA登記機構ID。
5.4 {#}被替換為一系列文件中檔案的位置，從「1」開始；如果是獨立檔案，則必須替換為「1」；
5.5 {rev}被替換為檔案的修訂（或重發）次數，從「0」開始：並且
5.6 {ext}如果是準同名文件的數字簽名檔案，則替換為「sig」。否則，則替換為「ryde」。
6.公鑰的分發. 每個註冊運營商和保管代理將通過電子郵件將其公鑰發送給另一方（註冊運營商或保管代理，視情況而定），發送至指定的電子郵件地址。每個方將通過回覆電子郵件確認收到另一方的公鑰，然後發送方將通過線下方法（如面對面會議、電話）再次確認傳輸的密鑰的真實性，
23
因此，公鑰傳輸會被認證給能夠透過分發方運營的郵件伺服器發送和接收郵件的用戶。保留代理、註冊運營商和ICANN將會以相同的程序交換公鑰。
7.存款通知. 隨著每筆存款的交付，註冊運營商將向保留代理和ICANN提供一份書面聲明（可以通過經過身份驗證的電子郵件發送），該聲明包括在存款創建時生成的報告副本，並聲明該存款已被註冊運營商檢查，且內容完整且準確。該聲明的準備和提交必須由註冊運營商或其指定人執行，但該指定人不得是保留代理或保留代理的任何關聯方。註冊運營商將在其聲明中包括存款的“id”和“resend”屬性。這些屬性在本附錄第九節，參考文獻一中說明。
如果尚未成為RFC，註冊運營商將使用截至2024年12月1日的最新草案版本的介面規範。註冊運營商可以自行選擇在2024年12月1日之後使用新版本的介面規範。一旦介面規範以RFC形式發佈，註冊運營商將在該發佈後不遲於180個日曆天內實施該版本的介面規範。
8.驗證程序.
1)每個已處理文件的簽名文件都會被驗證。
2)如果處理的文件是更大文件的一部分，則將其組合在一起。
3)每個在前一個步驟中獲得的文件隨後會被解密和解壓。
4)在前一步中包含的每個數據文件都會根據本附錄第9節的參考1所定義的格式進行驗證。
5)數據保管代理擴展驗證過程，如本附錄第9節的參考2所定義，以及任何其他在該參考中包含的數據保管驗證過程。
如果在任何步驟中發現任何不一致，則存款將被視為不完整。
9.參考文獻.
1)登記數據保管規範，https://www.rfc-editor.org/rfc/rfc8909.txt
2)域名註冊數據(DNRD)對象映射，https://www.rfc-editor.org/rfc/rfc9022.txt
24
3)OpenPGP消息格式，https://www.rfc-editor.org/rfc/rfc4880.txt
4)OpenPGP參數，https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml
5)ICANN對註冊機構和數據擔保代理的介面，https://datatracker.ietf.org/doc/draft-lozano-icann-registry-interfaces
25
.com註冊協議附錄2
擔保協議（模板格式）
本擔保協議（"擔保協議"）於[ ]（“生效日期”）生效，由VeriSign, Inc.（"註冊機構"）、[ ]（"擔保代理"），以及互聯網名稱與編號分配公司（"ICANN"）之間訂立。
初步聲明。 註冊機構打算根據本協議的定義和規定將"存款"交付給擔保代理。註冊機構希望擔保代理持有存款，並在本協議 herein 中描述的某些事件發生時，按照本協議的條款將存款（或其副本）交付給ICANN。
因此，鑑於上述原因和以下相互承諾，以及其他善意且有價值的考慮，雙方承認收到和足夠的考慮，特此協議如下：
1. 註冊機構的交付。 登記機構應全權負責將定義及描述於《數據保管規範》中，即附錄1A或附錄1（視情況而定）中的存款交付給保管代理人，此協議為登記機構與ICANN之間的.com登記協議（以下稱為《登記協議》），並通過本參考納入本文件（以下稱為《附錄1A》或《附錄1》，視情況而定）。登記機構可以選擇根據附錄1A或附錄1（視情況而定）或保管代理人和登記機構共同同意的方式向保管代理人交付存款。收到存款後，保管代理人應立即根據附錄1A或附錄1（視情況而定）處理存款並生成文件列表，保管代理人應在每個日曆月結束後的十（10）個工作日內，通過電子郵件或美國郵寄將該文件列表轉發給登記機構。在收到存款後的兩（2）個工作日內，保管代理人應驗證存款的格式是否正確且似乎完整，通過執行附錄1A或附錄1（視情況而定）中指定的驗證程序。除非保管代理人和ICANN同意以其他方式交付保管代理人已執行附錄1A或附錄1（視情況而定）中描述的驗證程序的書面證明以及該程序產生的驗證報告的副本，否則保管代理人應在每個月底的最後一個工作日向ICANN交付一份書面證明，證明其已對上個月收到的所有存款執行了附錄1A或附錄1（視情況而定）中描述的驗證程序，並應向ICANN交付該程序產生的驗證報告副本。如果保管代理人發現任何存款未通過驗證程序，則應在四十八（48）小時內通知ICANN和登記機構此類不合規情況。保管代理人應根據此處的條款和條件持有存款。
2. 複製。 保管代理人可以通過任何手段複製存款，以遵守本保管協議的條款和條件。或者，保管代理人可以通知登記操作員，合理要求登記操作員迅速複製存款並將其轉交給保管代理人。
26
3. 存款通知; 公鑰分發。
(a)隨著每筆存款的交付到保管代理人，登記操作員應根據本保管協議的條款和條件，向保管代理人和ICANN提供一份由登記操作員簽署的書面聲明。 第7節（存款通知） 的附錄1A或附錄1，視情況而定。保管代理人應在收到任何存款後的兩（2）個工作日內，通過電子郵件或電話通知登記操作員，或者根據登記操作員的其他要求，並通過ICANN的伺服器以電子方式使用API，通知其已收到登記操作員的存款，該API在本保管協議生效日期之前可在https://datatracker.ietf.org/doc/draft-lozano-icann-registry-interfaces找到。此外，保管代理人還應附上驗證報告的副本，以確認其已進行驗證過程。
(b)登記操作員和保管代理人將通過電子郵件將其公鑰分發給對方（登記操作員或保管代理人，視情況而定），電子郵件地址將另行指定。每一方將通過回覆電子郵件確認收到對方的公鑰，然後分發方將隨後通過離線方法（例如親自會議、電話等）再次確認傳輸的密鑰的真實性。這樣，公鑰傳輸就對能夠通過分發方運營的郵件伺服器發送和接收郵件的用戶進行了身份驗證。保管代理人、登記操作員和ICANN將按照相同的程序交換公鑰。
4. 由保管代理進行交付
4.1 由保管代理向ICANN交付。 保管代理僅在以下情況下將存款或其完整副本交付給ICANN：
(a)註冊管理者通知保管代理將該交付送至ICANN的具體地址，通知中隨附一份付款備註，以證明向保管代理支付了一百美元($100.00)的款項；或
(b)保管代理從ICANN收到：
(i)一份書面通知，表明註冊協議根據註冊協議第6條已最終、有效和合法終止，且未從仲裁者或法庭獲得禁止ICANN保護此保管中的數據的禁令或類似命令（"註冊終止"）；
(ii)一份書面聲明，表明ICANN之前已以書面形式通知註冊管理者該註冊終止；
(iii)一份書面要求，要求釋放並將存款交付給ICANN；
27
(iv)來自ICANN的書面承諾，保證所提供的存款僅將根據登記協議的條款使用；
(v)ICANN針對此次交付的具體指示；以及
(vi)付款匯款通知，以證明登記操作人向保管代理人支付一百美元（$100.00）的款項，或通過ICANN的電子郵件證明付款（ICANN會再由登記操作人報銷）；
(c)發布應根據以下第8(c)節進行。
4.2 按登記操作人的請求交付。 如果滿足上述第4.1(a)節的規定，保管代理人應在收到第4.1(a)節中指定的通知和支票後的二十四（24）小時內，根據適用的指示交付存款。
4.3 按ICANN的請求交付。 如果滿足上述第4.1(b)或4.1(c)節的規定，保管代理人應在收到上述各節中指定的所有文件後的二十四（24）小時內交付以下內容： (i) 向登記操作人提供所有此類文件的副本； (ii) 向ICANN提供，根據ICANN的具體指示，電子版的存款副本；但如果根據上述第4.1(c)節開始交付，則登記操作人可以在上述二十四（24）小時內向保管代理人支付所欠款項，保管代理人應不再向ICANN交付本節(ii)分項中指定的材料。在收到本節(i)分項下的通知後，登記操作人應在收到此類文件之日起三十（30）天內（"異議期限"）通知保管代理人其對向ICANN釋放存款的異議（"異議通知"），並要求根據以下條款將存款的副本權屬問題提交仲裁：
(a)發送異議通知不應延誤將押金交付給ICANN的過程。
(b)如果登記機構在異議期間向押金代理人發送異議通知，該事項應提交給美國仲裁協會選出的三名(3)仲裁員進行仲裁並解決，依據美國仲裁協會的規則。仲裁員應適用加利福尼亞州的法律，不包括其法律衝突規則。至少一名(1)仲裁員應對互聯網產業有合理的熟悉度。仲裁員的決定對所有相關方具有約束力和決定性，並可在具備管轄權的法院對其決定進行判決。由押金代理人產生的所有仲裁成本，包括合理的律師費和費用，應由在仲裁中未獲勝的當事方支付；但是，若仲裁在仲裁員作出決定之前達成和解，參與仲裁的各方應各自平等支付所有此類費用的一定百分比。
(c)儘管上述第4.3(b)條款，雙方同意根據本第4.3條款提出的任何仲裁不應重新評估、重新考慮或以其他方式對任何問題、原因
28
或其他聲明進行審查，這些問題在涉及雙方的仲裁或法院判決中已被決定，涉及登記協議和/或合作協議，任何根據第4.3條款提起的仲裁有關此類問題或聲明的決定均為無效、不可執行且不具約束力。根據登記協議和/或合作協議的任何終止或行動的適當性、有效性、合法性或效力，應僅通過該等各自協議所提供的程序和救濟進行確定，而不通過根據第4.3條款提起的任何仲裁。根據第4.3條款提出的任何仲裁程序僅限於確定第4.1(b)和(c)條款是否已滿足。
(d)登記機構可在仲裁程序開始之前的任何時候，通知保管代理人登記機構已撤回反對通知。收到登記機構的任何此類通知後，保管代理人應根據ICANN提供的指示立即將存款交付給ICANN。
(e)如果根據第4.3節向ICANN釋放資料在任何根據第4.3節提起的仲裁中被判定為適當，保管代理人應根據上文第4.1(b)(v)節中的指示，立即將任何未先前交付的存款交付給ICANN。所有各方同意在所有應支付給保管代理人的費用被支付之前，保管代理人無需交付這些存款。
(f)如果根據第4.3節向ICANN釋放存款在任何根據第4.3節提起的仲裁中被判定為不當，ICANN應根據登記機構的酌情權，立即歸還或銷毀那些根據第4.3節收到的存款。
4.4 保管代理人向登記機構的交付。 根據本保管協議第7(a)或7(b)節的規定，保管代理人應在本保管協議終止時，向登記機構釋放並交付存款。
5. 賠償。
一般賠償責任。 根據下面第11(a)節的限制，登記機構和ICANN應共同和各自承擔賠償責任，使保管代理人及其每位董事、管理人員、代理人和員工（"保管代理人賠償人"）在與本保管協議或保管代理人或任何保管代理人賠償人在本協議下的履行相關的任何及所有索賠、訴訟、損害賠償、責任、義務、成本、費用、收費及任何其他費用，包括合理的律師費和費用，完全且永遠地免受損害，除非與保管代理人及其董事、管理人員、代理人、員工或承包商的失實陳述、過失或不當行為相關的任何索賠、行動、損害賠償、責任、義務、成本、費用、收費或任何其他費用。根據第11(a)節的限制，保管代理人同樣應賠償並使登記機構和ICANN及其各自的董事、管理人員、代理人和員工（"賠償人"）完全且永遠地免受任何及所有索賠、行動、損害賠償、責任、義務、成本、費用、收費及任何其他費用的損害，
29
包括合理的律師費和費用，可能由第三方對任何 indemnity 相關方提出，與保管代理人的虛假陳述、過失或不當行為有關，保管代理人及其董事、高級職員、代理人、員工和承包商。
6. 争议和交叉索赔。
(a) 保管代理人可以在接收第 4 節中的異議通知後，向任何有管轄權的法庭提交根據本保管協議的任何爭議，以進行交叉索賠或類似訴訟，而不包括提交仲裁的事項。根據本保管協議第 4 節的描述，相關各方提交該事宜進行仲裁。與此相關的保管代理人所產生的任何及所有費用，包括合理的律師費和費用，應由登記運營商和 ICANN 各分擔 50%。
(b) 保管代理人應執行任何有管轄權的法院所命令的行為，對於任何一方因該行為而產生的任何責任或義務，不承擔相關責任。
7. 期限和續約。
(a)本保管協議的初始有效期應自本協議生效日期起開始，並在其後持續五（5）年（「初始期限」）。本保管協議應在初始期限結束時自動延長為一年的額外條款（每個為「額外期限」），並在每個額外期限結束時進行。初始期限及每個額外期限合稱「期限」。保管代理人單獨行使或登記運營商需獲得 ICANN 的同意，可以在提前通知其他各方 90 天的情況下隨時終止本保管協議。
(b)如果登記運營商根據上述第 7(a) 節發出其終止意圖的通知，且 ICANN 根據第 7(a) 節未能同意，則 ICANN 應負責支付所有後續費用，並有權要求從登記運營商處獲得這些費用的報銷，並在提前通知其他各方 90 天的情況下隨時終止本保管協議。
(c)在根據本協議第7(a)或7(b)條款終止本託管協議的情況下，登記運營商應支付託管代理人所有應付費用，並應立即通知ICANN本託管協議已被終止，託管代理人應將其所持有的所有存款副本返還給登記運營商。
8. 費用和發票。
(a) 费用。 登記運營商應根據第8條（費用和發票）提前支付附件A中規定的年費（通過本參考納入），以換取託管代理人在本託管協議下提供的服務。
30
(b) 發票付款。 登記運營商應在發票日期後的三十（30）天內支付有效且正確提交的發票；但登記運營商不必支付任何善意爭議的金額。登記運營商應在善意爭議發票或任何部分時以書面形式通知託管代理人，說明爭議的原因，雙方同意善意協商解決該爭議的發票；但如果雙方無法合理地就爭議的費用達成一致，雙方應將該爭議上報至適當的董事/副總裁層級以解決該爭議。向託管代理人的付款應發送至託管代理人發票上列明的匯款地址。
(c) 不付款。 在未支付託管代理人開具的任何費用或收費的情況下，託管代理人應向登記運營商發出未付款的通知，在這種情況下，登記運營商有權在收到託管代理人的通知後十（10）個工作日內支付未付款項。如果登記運營商在該十（10）天期內未能全額支付到期的所有費用，託管代理人應向ICANN發出未付款的通知，在這種情況下，ICANN有權在收到託管代理人的通知後十（10）個工作日內支付未付款項。無論是登記運營商還是ICANN支付未付款項後，本託管協議應繼續全力有效，直到適用的期限結束。若登記運營商或ICANN未能根據本第8(c)條款，或根據第4.3條款，由登記運營商未支付未付款項，託管代理人應依據第4.3條款進行處理，假設ICANN要求交付存款。
(d) 發票提交地址。 托管 代理人應於本託管協議生效日期及每年隨後的生效日期周年日向登記運營商開具年度費用的發票。如果在當前期限結束之前終止本託管協議，託管代理人應向登記運營商或ICANN退還根據第8(c)條款ICANN支付給託管代理人的費用的按比例計算的年度費用的一部分。對於雙方在簽署的書面文件中可能同意的任何額外工作，託管代理人應提交詳細且及時的發票，頻率不超過每月一次，且不得晚於完成額外服務後九十（90）天。根據本託管協議所發出的所有發票應引用分配給該工作的採購訂單號。託管代理人不得向登記運營商提交不引用適用的採購訂單號的發票，但登記運營商應及時提供託管代理人相關的採購訂單號。託管代理人應僅向登記運營商的應付帳款部門提交原始發票，地址如下所示：
發票提交地址：
VeriSign, Inc.
12061 Bluemont Way
維珍尼亞州雷斯頓 20190
收件人：應付帳款
31
或發票可以電子方式提交至：accountspayable@verisign.com
9. 存款的所有權。 各方承認並確認，在本保管協議有效期間，存款的所有權始終歸登記運營商所有。
10. 保留和保密.
(a)保留保管代理人應持有並維護存款，期限不得少於三百六十五（365）天，並存放在安全、鎖閉且環境安全的設施中，該設施僅可由保管代理人的授權代表進入。保管代理人應盡商業上合理的努力保護存款的完整性。ICANN和登記運營商均有權在合理的事先通知和正常工作時間內檢查保管代理人就本保管協議所做的書面記錄。
(b)保密保管代理人應在所有時候保護存款的保密性。除本保管協議中規定的情況外，保管代理人不得披露、轉讓、提供或使用任何存款（或任何存款的副本）。如果保管代理人收到通知，要求其根據法規、規則、法令或其他政府機構、立法機構、具管轄權的法院或具約束力的仲裁機構的要求披露任何存款（除本保管協議第4或第8(c)條款所要求的情況），保管代理人應在七（7）天內通知ICANN和登記運營商，或在合理可行的情況下盡快通知，並合理合作與登記運營商和/或ICANN進行披露的抗辯。如果任何抗辯未能成功，保管代理人對根據這類政府的、立法的、司法的或仲裁的命令、法規、規則、法令或其他要求所做的任何披露不承擔責任。
11. 其他事項。
(a)補救措施；責任限制。
(i)除非因(i)死亡或人身傷害；或(ii)重大過失或故意不當行為，在登記運營商和/或ICANN與托管代理之間的任何爭議中，托管代理、登記運營商和/或ICANN對本托管協議的任何相關責任（如有），不論是基於合同、侵權（包括過失）或其他原因，均應限制於根據本托管協議向托管代理支付的當年費用。
(ii)在登記運營商和ICANN之間，登記協議的責任限制也適用。
(iii)在任何情況下，本托管協議的任何一方不得對另一方承擔任何附帶的、特別的、懲罰性的或結果性的損害賠償、損失的利潤、任何替代服務的採購成本或費用（不包括替代托管服務），或任何其他間接損害，不論是基於合同、侵權（包括過失）或其他原因，即使其可能性事先已為一或多方所知。
32
(iv)每一方明確保留根據法律或衡平法強制執行本托管協議條款的所有權利，但僅限於本第11(a)條中規定的限制。
(b)允許依賴和不作為。 托管代理可以依賴並在根據任何托管代理善意相信是真實的通知或其他文件上行事或不作為，並且應受到充分保護，該文件已由正當的個人或實體簽署或呈交。托管代理僅具有本協議中明確規定的義務和責任。
(c)獨立承包商。 保管代理是一名獨立承包商，並不是登記操作商或ICANN的員工或代理。
(d)修訂。 本保管協議不得修改或修訂，除非由本協議各方簽署的另一書面協議。
(e)作業。 登記操作商和ICANN不得轉讓或轉移本保管協議（通過合併、資產出售、法律運作或其他方式），除非登記操作商或ICANN的權利和義務自動轉移至這些方之一的權利和義務的受讓人。然而，保管代理在執行本保管協議時，無需承認登記操作商或ICANN的任何繼任者或受讓人，除非保管代理收到明確、權威和確定的書面證據，證明當事方的變更。保管代理不得在未經登記操作商和ICANN雙方事先書面同意的情況下轉讓或轉移本保管協議，而該同意不應不合理地延遲或拒絕。
(f)完整協議。 本保管協議，包括所有附錄（如有），取代保管代理和其他方之間有關本協議所載事項的所有先前討論、理解和協議，並構成保管代理與其他方之間關於此處所考慮事項的完整協議。登記協議的附錄1A或附錄1（視情況而定）特此通過引用成為本保管協議的一部分，並合併於此。
(g)對應文件；適用法律。 本保管協議可以簽署為多份副本，每份副本在簽署後應被視為原件，所有副本合併在一起應構成一份同一協議。該保管協議應受加利福尼亞州法律的管轄並根據其法律解釋，而不考慮其法律衝突原則。除非在此特別規定，所有各方亦同意加利福尼亞州的個人管轄權，承認在加利福尼亞的任何州及聯邦法院內場地適當，同意在這些法院中就任何與本保管協議有關的行動進行訴訟，並放棄對於上述任何事項的異議。
(h)注意事項。 根據本保管協議要求或允許發出的所有通知、請求、要求或其他通信應以書面形式給出，並應由人員親自遞交或通過提供回執的商業隔夜快遞服務遞送，或郵寄已簽收的
33
郵件，要求回執，郵資已付。如果是親自遞交或通過商業隔夜快遞服務遞送，則通知、請求、指示或文件交付的日期應視為交付日期；如果通過郵寄遞送，則該通知、請求、指示或文件被接收的日期應視為交付日期。任何一方可以通過向其他各方書面通知來更改其在本保管協議下的地址。
(i)生存。 第5、6、8、9、10和11條在本保管協議終止後仍然有效。
(j)不得豁免。 任何一方未能行使，或任何一方在行使任何權利、權力或對任何權利、權力或救濟的部分或單一行使上所產生的延遲，均不會排除任何其他或進一步的行使，或對任何其他權利、權力或救濟的行使。本協議中任何一方對任何條款或條件的違反或失職的明示放棄或同意，均不應構成對相同或任何其他條款或條件以後違反或失職的放棄或同意。
兹為證，各方已使其正式授權的官員於生效日期簽署本託管協議。
[ ]
作者：
標題：
姓名（正楷）：
日期：
地址：
電話：
電子郵件：
VeriSign, Inc.
簽署：
職稱：
打印姓名：
日期：
地址：
電話：
電子郵件:
互聯網名稱與號碼指派公司
由:
職稱:
34
姓名（印刷體）:
日期:
地址:
電話:
電子郵件：
35
附錄2的附表A
1. 年度費用。 年度費用應為[ ]美金。
2. 測試期間。 儘管本保管協議中有任何相反的條款，自保管協議的生效日起，直至註冊機構合理確定並透過通知（可通過電子郵件方式）告知ICANN和保管代理，保管代理將與傳統保管代理平行執行本保管協議中列明的服務，以示保管代理已做好執行準備（以下稱為“測試期間”）。ICANN理解並同意在測試期間，傳統保管代理將繼續是唯一的權威保管服務來源。
36
.com 註冊協議附錄3
區域檔案存取
1.第三方區域檔案訪問
1.1區域檔案訪問協議登記管理者將與任何互聯網用戶簽訂協議，允許該用戶訪問由登記管理者指定的互聯網主機伺服器或伺服器，並下載區域檔案數據。該協議將由集中式區域數據訪問提供者統一、促進和管理，該提供者可以是ICANN或ICANN指定的人（以下稱「CZDA提供者」）。登記管理者（可選擇通過CZDA提供者）將根據本附錄第1.3節提供區域檔案數據的訪問，並使用本附錄第1.4節描述的檔案格式進行操作。儘管如此，
(a) CZDA提供者可以拒絕任何不符合本附錄第1.2節的認證要求的用戶的訪問請求；(b) 登記管理者可以拒絕任何未提供正確或合法證明的用戶的訪問請求，根據本附錄第1.2節，或登記管理者合理地相信該用戶會違反本附錄第1.5節的條款；(c) 若登記管理者有證據支持該用戶違反本附錄第1.5節的條款，可以撤銷該用戶的訪問。
1.2認證要求登記管理者將通過CZDA提供者的促進，要求每個用戶提供足夠的信息以正確識別和定位該用戶。該用戶信息將包括但不限於公司名稱、聯繫人姓名、地址、電話號碼、傳真號碼、電子郵件地址和IP地址。
1.3訪問授權每個登記管理者（可選擇通過CZDA提供者）將為用戶提供一個ICANN指定和管理的URL（特定為<TLD>.zda.icann.org，其中<TLD>是該登記負責的頂級域名）以訪問登記的區域數據檔案存檔。登記管理者將授予用戶一個非獨佔、不可轉讓的有限權利，以訪問登記管理者的（可選CZDA提供者的）區域檔案託管伺服器，並在每24小時內傳輸一次頂級域名區域檔案的副本，以及任何相關的加密檢查和校驗檔案，使用SFTP或ICANN可能規定的其他數據傳輸和訪問協議。對於每個區域檔案訪問伺服器，區域檔案在名為的頂級目錄中。
<zone>.zone.gz，並附有<zone>.zone.gz.md5和<zone>.zone.gz.sig以驗證下載。如果登記運營商（或CZDA提供者）也提供歷史數據，將使用命名模式<zone>-yyyymmdd.zone.gz等。
1.4檔案格式標準登記運營商（可選通過CZDA提供者）將使用標準主檔格式的子格式提供區域檔案，該格式最初在
37
RFC 1035，第5節，包括公共DNS中使用的實際區域中存在的所有記錄。子格式如下：
1.每個記錄必須包含所有字段，格式為：<domain‐name> <TTL> <class> <type>
<RDATA>。
2.類型和類別必須使用標準助記符，並且必須使用小寫字母。
3.TTL必須以十進制整數形式存在。
4.在網域名稱中允許使用 \X 和 \DDD。
5.所有網域名稱必須使用小寫字母。
6.必須使用正好一個製表符作為記錄內欄位的分隔符。
7.所有網域名稱必須是完全合格的。
8.不允許 $ORIGIN 指令。
9.不允許使用 “@” 來表示當前來源。
10.不允許在記錄的開頭使用 “空白域名稱” 以繼續使用前一個記錄中的域名稱。
11.不允許 $INCLUDE 指令。
12.無$TTL指令。
13.不使用括號，例如，無法在行邊界繼續記錄中的字段列表。
14.不使用註解。
15.不允許空白行。
16.SOA記錄應位於區域文件的頂部並（在）文件的末尾重複。
17.除了SOA記錄之外，文件中的所有記錄必須按字母順序排列。
18.每個文件僅包括一個區域。如果一個TLD將其DNS數據分成多個區域，則每個區域放入上述命名的單獨文件中，所有文件合併使用tar生成一個名為
<tld>.zone.tar。
1.5Use of Data by User. Registry Operator will permit user to use the zone file for lawful purposes; provided that (a) user takes all reasonable steps to protect against unauthorized access to, use of, and disclosure of the data, and (b) under no circumstances will Registry
38
Operator be required or permitted to allow user to use the data to (i) allow, enable or otherwise support any marketing activities to entities other than the user’s existing customers, regardless of the medium used (such media include but are not limited to transmission by e-mail, telephone, facsimile, postal mail, SMS, and wireless alerts of mass unsolicited, commercial advertising or solicitations to entities), (ii) enable high volume, automated, electronic processes that send queries or data to the systems of Registry Operator or any ICANN-accredited registrar, or (iii) interrupt, disrupt or interfere in the normal business operations of any registrant.
1.6Term of Use. Registry Operator, through CZDA Provider, will provide each user with access to the zone file for a period of not less than three (3) months. Registry Operator will allow users to renew their Grant of Access.
1.7No Fee for Access. Registry Operator will provide, and CZDA Provider will facilitate, access to the zone file to user at no cost.
2.Co‐operation
2.1 協助登記運營商將與ICANN及CZDA提供者合作，並提供合理的協助，以便促進和維持根據本附錄規定，允許用戶對區域檔案數據的有效訪問。
2.2 ICANN訪問登記運營商應持續向ICANN或其指定者提供TLD的區域檔案的批量訪問，方式應根據ICANN不時合理指定的方式進行。訪問將至少每日提供。區域檔案將包括儘可能靠近00:00:00 UTC的SRS數據。
39
.com登記協議附錄4
登記運營商的格式和內容
每月報告
登記運營商應每月提供以下報告，每份報告的詳細說明如下： (1) 服務水平協議績效報告； (2) 每登記商交易報告；及 (3) 登記功能活動報告。服務水平協議績效報告應通過電子郵件提交至ICANN，郵件地址為 <registry-reports@icann.org>。每登記商交易報告及登記功能活動報告應使用在draft-lozano-icann-registry-interfaces中描述的API提交給ICANN，詳情可參見https://datatracker.ietf.org/doc/draft-lozano-icann-registry-interfaces（“登記接口規範”）。 如果尚未成為RFC，登記運營商將使用截至2024年12月1日可用的最新草案版本的登記接口規範。登記運營商可選擇在2024年12月1日後使用新的登記接口規範版本。一旦登記接口規範作為RFC發布，登記運營商將在其發布後不超過一百八十（180）個日曆日內實施RFC版本。
ICANN將來可能會要求以其他方式和其他格式提交報告。對於每一份報告，ICANN將用合理的商業努力來保護報告中信息的機密性，直到該報告所涉及的月份結束後三（3）個月為止。除非在本附錄4中另有規定，否則任何對具體時間的引用均指協調世界時間（UTC）。每月報告應由反映註冊處在該月份結束時（UTC）狀態的數據組成。
1.服務水平協議表現報告本報告應比較服務水平協議要求與報告月份的實際表現指標：（a）根據附錄7的第7.2節；以及（b）根據附錄50億的第3.2節。
2.每註冊商交易報告本報告應以RFC 4180中指定的逗號分隔值格式的文件進行編制。該文件應命名為“com-transactions-yyyymm.csv。”該文件應包含每個註冊商的以下字段：
40
字段編號 | 字段名稱 | 描述 | ||||||
01 | 註冊者名稱 | 註冊者的完整公司名稱，按IANA註冊 | ||||||
02 | iana-id | 在註冊機構作為註冊者的情況下（即不使用ICANN認可的註冊者）應使用9998或9999，具體取決於註冊類型，否則應使用贊助註冊者的IANA id，具體請參閱https://www.iana.org/assignments/registrar-ids | ||||||
03 | 總域名 | 根據任何EPP狀態，但未處理的pendingCreate下的總域名數量 | ||||||
04 | 總名稱伺服器 | 與註冊於該TLD的域名相關的總名稱伺服器（無論是主機對象還是作為域名屬性的名稱伺服器主機），在任何EPP狀態下，但未處理的pendingCreate下的總名稱伺服器數量 | ||||||
05 | 網絡新增-1年 | 成功註冊的域名數量（即，未處於EPP pendingCreate狀態）初始期限為一年（1年）（且在新增寬限期內未被刪除）。交易必須在新增寬限期結束的月份報告。 | ||||||
06 | 網絡新增-2年 | 成功註冊的域名數量（即，未處於EPP pendingCreate狀態）初始期限為兩年（2年）（且在新增寬限期內未被刪除）。交易必須在新增寬限期結束的月份報告。 | ||||||
07 | 網絡新增-3年 | 成功註冊的域名數量（即，未處於EPP pendingCreate狀態）初始期限為三年（3年）（且在新增寬限期內未被刪除）。交易必須在新增寬限期結束的月份報告。 | ||||||
08 | 網絡新增-4年 | 成功註冊的域名數量（即，未處於EPP pendingCreate狀態）初始期限為四年（4年）（且在新增寬限期內未被刪除）。交易必須在新增寬限期結束的月份報告。 | ||||||
41
09 | 淨增-5年 | 成功註冊的域名數量（即不在EPP pendingCreate狀態）初始期限為五（5）年（且在新增寬限期內未被刪除）。交易必須在新增寬限期結束的月份報告。 | ||||||
10 | 淨增-6年 | 成功註冊的域名數量（即不在EPP pendingCreate狀態）初始期限為六（6）年（且在新增寬限期內未被刪除）。交易必須在新增寬限期結束的月份報告。 | ||||||
11 | 淨增-7年 | 成功註冊的域名數量（即不在EPP pendingCreate狀態）初始期限為七（7）年（且在新增寬限期內未被刪除）。交易必須在新增寬限期結束的月份報告。 | ||||||
12 | 淨增-8年 | 成功註冊的域名數量（即不在EPP pendingCreate狀態）初始期限為八（8）年（且在新增寬限期內未被刪除）。交易必須在新增寬限期結束的月份報告。 | ||||||
13 | 淨新增域名 - 9 年 | 成功註冊的域名數量（即不處於 EPP pendingCreate 狀態），初始期限為九（9）年（且在新增寬限期內未被刪除）。交易必須在新增寬限期結束的月份報告。 | ||||||
14 | 淨新增域名 - 10 年 | 成功註冊的域名數量（即不處於 EPP pendingCreate 狀態），初始期限為十（10）年（且在新增寬限期內未被刪除）。交易必須在新增寬限期結束的月份報告。 | ||||||
15 | 淨續費域名 - 1 年 | 成功續費的域名數量（即不處於 EPP pendingRenew 狀態），無論是自動續期或通過指令，新的續費期限為一年（1 年）（且在續費或自動續費寬限期內未被刪除）。交易必須在續費或自動續費寬限期結束的月份報告。 | ||||||
42
16 | 淨續費域名 - 2 年 | 成功續費的域名數量（即不處於 EPP pendingRenew 狀態），無論是自動續期或通過指令，新的續費期限為兩年（2 年）（且在續費或自動續費寬限期內未被刪除）。交易必須在續費或自動續費寬限期結束的月份報告。 | ||||||
17 | 淨續約-3年 | 成功續約的域名數量（即不在EPP待續約狀態）無論是自動續約或通過 命令並有新的續約期限為三（3）年（並且不在續約或自動續約的寬限期被刪除）。交易必須在續約或自動續約寬限期結束的月份報告。 | ||||||
18 | 淨續約-4年 | 成功續約的域名數量（即不在EPP待續約狀態）無論是自動續約或通過命令，並有新的續約期限為四（4）年（並且不在續約或自動續約的寬限期被刪除）。交易必須在續約或自動續約寬限期結束的月份報告。 | ||||||
19 | 淨續約-5年 | 成功續約的域名數量（即不在EPP待續約狀態）無論是自動續約或通過命令，並有新的續約期限為五（5）年（並且不在續約或自動續約的寬限期被刪除）。交易必須在續約或自動續約寬限期結束的月份報告。 | ||||||
20 | 淨續約-6年 | 成功續訂的域名數量（即不在EPP待續訂狀態）無論是自動或通過命令進行，續訂期間為六（6）年（且在續訂或自動續訂寬限期內未被刪除）。交易必須在續訂或自動續訂寬限期結束的月份進行報告。 | ||||||
21 | 淨續訂-7年 | 成功續訂的域名數量（即不在EPP待續訂狀態）無論是自動或通過命令進行，續訂期間為七（7）年（且在續訂或自動續訂寬限期內未被刪除）。交易必須在續訂或自動續訂寬限期結束的月份進行報告。 | ||||||
43
22 | 淨續訂-8年 | 成功續訂的域名數量（即不在EPP待續訂狀態）無論是自動或通過命令進行，續訂期間為八（8）年（且在續訂或自動續訂寬限期內未被刪除）。交易必須在續訂或自動續訂寬限期結束的月份進行報告。 | ||||||
23 | 淨續訂-9年 | 成功續訂的域名數量（即不在EPP待續訂狀態）無論是自動或通過命令進行，續訂期間為九（9）年（且在續訂或自動續訂寬限期內未被刪除）。交易必須在續訂或自動續訂寬限期結束的月份進行報告。 | ||||||
24 | 淨續訂-10年 | 成功續訂的域名數量（即，未處於EPP待續訂狀態），無論是自動續訂還是通過命令續訂，且續訂期為十（10）年（且在續訂或自動續訂的寬限期內未被刪除）。交易必須在續訂或自動續訂寬限期結束的月份報告。 | ||||||
25 | 轉移獲取成功 | 由此註冊商啟動的成功完成的域名轉移數量（無論是明確批准或自動批准），且在轉移寬限期內未被刪除。交易必須在轉移寬限期結束的月份報告。 | ||||||
26 | 轉移獲取拒絕 | 由此註冊商啟動的域名轉移數量被其他註冊商拒絕（例如，EPP轉移操作="拒絕"） | ||||||
27 | 轉移失去成功 | 由其他註冊商啟動的成功完成的域名轉移數量（無論是明確批准或自動批准） | ||||||
28 | 轉移失去拒絕 | 由另一個註冊商發起但此註冊商拒絕的域名轉移數量（例如，EPP轉移操作="拒絕"） | ||||||
29 | 轉移爭議—獲勝 | 此註冊商獲勝的轉移爭議數量（在裁定發生的月份報告） | ||||||
44
30 | 轉移爭議—失敗 | 此註冊商失敗的轉移爭議數量（在裁定發生的月份報告） | ||||||
31 | 轉移爭議—無裁定 | 涉及此註冊商的轉移爭議數量，裁定不明或無裁定（在裁定發生的月份報告） | ||||||
32 | 已刪除域名的寬限期 | 在添加寬限期內刪除的域名（不包括在EPP pendingCreate狀態下刪除的名稱）。刪除必須在名稱被清除的當月報告。 | ||||||
33 | 已刪除的域名-無寬限期 | 在添加寬限期外刪除的域名（不包括在EPP pendingCreate狀態下刪除的名稱）。刪除必須在名稱被清除的當月報告。 | ||||||
34 | 恢復的域名 | 在報告期間內恢復的域名名稱 | ||||||
35 | 無報告的恢復 | 需要註冊機構提交恢復報告的總恢復名稱數量，但註冊商未能提交 | ||||||
36 | AGP豁免請求 | 總數據的AGP（加寬寬限期）豁免申請數量 | ||||||
37 | AGP豁免已授予 | 總數據的AGP（加寬寬限期）豁免申請已授予 | ||||||
38 | AGP豁免的域名 | 因已授予AGP（加寬寬限期）豁免申請而受影響的總名稱數量 | ||||||
39 | 嘗試添加 | 嘗試創建的域名命令數量（包括成功和失敗） | ||||||
40 | 合併交易天數 | 通過合併/同步交易添加到所有域名到期日期的天數總數。合併/同步交易的天數必須在交易發生的月份報告於此。 | ||||||
41 | 合併交易 | 合併/同步交易的總數。一個交易必須在交易發生的月份報告於此。 | ||||||
第一行應包含如上表所述的字段名稱，作為第2節RFC 4180中所描述的“標頭行”。每份報告的最後一行應包括所有註冊商的每列總計；該行的第一個字段應顯示“總計”，而第二個字段在該行中應留空。除了上述所描述的行外，不應包含其他行。行分隔符應為<U+000D, U+000A>，如RFC 4180中所述。
45
3.註冊處功能活動報告本報告應編寫為以逗號分隔的值格式的文件，如RFC 4180所指定。文件應命名為“com-activity-yyyymm.csv”。該文件應包含以下字段：
字段 # | 字段名稱 | 描述 | ||||||
01 | 運營登記機構 | 報告期末生產系統中運營登記機構的數量 | ||||||
02 | 區域檔案訪問密碼 | 報告期末處於活動狀態的區域檔案訪問密碼的數量；如果使用中央區域數據服務（CZDS）提供區域檔案給最終用戶，可以用"CZDS"替代活動的區域檔案訪問密碼的數量 | ||||||
03 | whois-43查詢 | 報告期內回應的WHOIS（端口-43）查詢數量 | ||||||
04 | 網頁WHOIS查詢 | 在報告期間內，網路型WHOIS查詢的回應次數，不包括可搜尋的WHOIS | ||||||
05 | 可搜尋的WHOIS查詢 | 在報告期間內，回應的可搜尋WHOIS查詢的次數 | ||||||
06 | 接收的DNS UDP查詢 | 在報告期間內，透過UDP傳輸接收到的DNS查詢數量 | ||||||
07 | 回應的DNS UDP查詢 | 在報告期間內，對透過UDP傳輸接收到的DNS查詢進行回應的數量 | ||||||
08 | 接收的DNS TCP查詢 | 在報告期間通過TCP傳輸接收到的DNS查詢數量 | ||||||
09 | dns-tcp-queries-responded | 在報告期間通過TCP傳輸接收到的DNS查詢中被回應的數量 | ||||||
10 | srs-dom-check | 在報告期間針對SRS（EPP和任何其他介面）域名“檢查”請求的回應數量 | ||||||
11 | srs-dom-create | 在報告期間針對SRS（EPP和任何其他介面）域名“創建”請求的回應數量 | ||||||
12 | srs-dom-delete | 在報告期間，處理的SRS（EPP及其他介面）域名「刪除」請求數量 | ||||||
46
13 | srs-dom-info | 在報告期間，處理的SRS（EPP及其他介面）域名「信息」請求數量 | ||||||
14 | srs-dom-renew | 在報告期間，處理的SRS（EPP及其他介面）域名「續訂」請求數量 | ||||||
15 | srs-dom-rgp-restore-report | 在報告期間，處理的SRS（EPP及其他介面）域名RGP「恢復」請求傳送的恢復報告數量 | ||||||
16 | srs-dom-rgp-restore-request | 在報告期間內針對SRS（EPP和其他介面）域名RGP“恢復”請求的響應數量 | ||||||
17 | srs-dom-transfer-approve | 在報告期間內針對SRS（EPP和其他介面）域名“轉移”請求的批准轉移響應數量 | ||||||
18 | srs-dom-transfer-cancel | 在報告期間內針對SRS（EPP和其他介面）域名“轉移”請求的取消轉移響應數量 | ||||||
19 | srs-dom-transfer-query | 在報告期間內針對SRS（EPP和其他介面）域名“轉移”請求的查詢響應數量 | ||||||
20 | srs-dom-transfer-reject | 在報告期內，拒絕的SRS（EPP及其他接口）域名「轉移」請求數量 | ||||||
21 | srs-dom-transfer-request | 在報告期內，請求轉移的SRS（EPP及其他接口）域名「轉移」請求數量 | ||||||
22 | srs-dom-update | 在報告期內，回應的SRS（EPP及其他接口）域名「更新」請求數量（不包括RGP恢復請求） | ||||||
23 | srs-host-check | 在報告期內，回應的SRS（EPP及其他接口）主機「檢查」請求數量 | ||||||
24 | srs-host-create | 在報告期間內，回應的SRS（EPP及其他介面）主機「創建」請求的數量 | ||||||
47
25 | srs-host-delete | 在報告期間內，回應的SRS（EPP及其他介面）主機「刪除」請求的數量 | ||||||
26 | srs-host-info | 在報告期間內，回應的SRS（EPP及其他介面）主機「信息」請求的數量 | ||||||
27 | srs-host-update | 在報告期間內，回應的SRS（EPP及其他介面）主機「更新」請求的數量 | ||||||
28 | srs-cont-check | 在報告期間內回應的SRS（EPP和任何其他介面）聯絡“檢查”請求的數量 | ||||||
29 | srs-cont-create | 在報告期間內回應的SRS（EPP和任何其他介面）聯絡“創建”請求的數量 | ||||||
30 | srs-cont-delete | 在報告期間內回應的SRS（EPP和任何其他介面）聯絡“刪除”請求的數量 | ||||||
31 | srs-cont-info | 在報告期間內回應的SRS（EPP和任何其他介面）聯絡“信息”請求的數量 | ||||||
32 | srs-cont-transfer-approve | 在報告期間回應的SRS（EPP及任何其他介面）聯絡「轉移」請求的數量 | ||||||
33 | srs-cont-transfer-cancel | 在報告期間回應的SRS（EPP及任何其他介面）聯絡「撤銷轉移」請求的數量 | ||||||
34 | srs-cont-transfer-query | 在報告期間回應的SRS（EPP及任何其他介面）聯絡「查詢轉移」請求的數量 | ||||||
35 | srs-cont-transfer-reject | 在報告期間回應的SRS（EPP及任何其他介面）聯絡「拒絕轉移」請求的數量 | ||||||
36 | srs-cont-transfer-request | 在報告期間內，SRS（EPP及任何其他介面）聯絡「轉移」請求的數量以及回應的請求數 | ||||||
37 | srs-cont-update | 在報告期間內，SRS（EPP及任何其他介面）聯絡「更新」請求的數量以及回應的請求數 | ||||||
38 | rdap-queries | 在報告期間內，回應的RDAP查詢數量。 | ||||||
48
第一行應包括如上表所述的字段名稱，作為RFC 4180第2節所述的「標題行」。除了上述描述的行外，不應包含其他行。行中斷應為<U+000D, U+000A>，如RFC 4180所述。
對於作為單例共享註冊系統的一部分的TLD： (1) 於登記功能活動報告中，whois-43-queries、web-whois-queries、searchable-whois-queries和rdap-queries字段應與單個實例共享註冊系統中對應的TLD報告的查詢總和匹配，登記操作人有靈活的選擇如何在使用單例共享註冊系統的TLD中分配這些查詢，(2) 若登記操作人不能確定查詢應計入的TLD（例如，對於運作於多個共享相同RDAP基本URL的TLD的註冊商查詢），則登記操作人有靈活的選擇如何在使用單例共享註冊系統的TLD中分配這些查詢，(3) 登記功能活動報告可以包括系統中所有TLD的總聯絡或主機交易數量。
49
.com登記協議附錄5A
註冊數據發布服務規範
電腦系統、電子儲存裝置、電子郵件帳號、雲端儲存帳號、社交媒體帳號和其他我擁有或控制的設備或媒體中的所有所有機密資訊和聯繫，與我定義.
i. 註冊數據目錄服務註冊數據目錄服務或 "RDDS" 是指WHOIS數據目錄服務（如本附錄5A定義）和RDAP目錄服務的集合，如附錄50億中所定義。
ii. WHOIS數據目錄服務WHOIS數據目錄服務是指根據RFC 3912通過43端口提供的WHOIS服務以及提供公共查詢訪問登記數據的基於網頁的WHOIS服務的集合。
1. WHOIS數據目錄服務. 登記運營商將根據RFC 3912運營一個通過端口43提供的WHOIS服務，以及一個基於網絡的WHOIS服務，網址為<www.verisign.com/whois>，提供免費的公共詢問訪問，至少包含以下元素及其格式。
1.1 響應的格式應遵循下面所述的半自由文本格式，隨後是一個空行和一個法律聲明，指定登記運營商及查詢數據庫的用戶的權利。
1.2 每個數據對象應表示為一組鍵/值對，行以鍵開始，後面跟著冒號和空格作為分隔符，再跟著值。
1.3 對於存在多個值的字段，應允許具有相同鍵的多個鍵/值對（例如列出多個名稱伺服器）。空行後的第一個鍵/值對應被視為新記錄的開始，並應被視為識別該記錄，並用於將數據分組，如主機名和IP地址，或域名和註冊信息。
1.4 下面指定的字段列出了最小輸出要求。登記運營商必須僅實施與其運營的TLD類型相關的《登記註冊數據目錄服務一致標籤和顯示政策》（https://www.icann.org/resources/pages/rdds-labeling-policy-2024-02-21-en）結合本附錄5A，與“厚”或“薄”登記模型相關（例如，排除與任何聯繫人相關的信息：註冊人、管理員、技術、計費等）。截至生效日期，.com TLD被視為“薄”登記模型。
1.5 域名數據
50
1.5.1 查詢格式： whois EXAMPLE.TLD
1.5.2 回應格式：
域名：EXAMPLE.TLD
註冊域名ID：D1234567-TLD
註冊商WHOIS伺服器：whois.example.tld
註冊商網址： http://www.example.tld 更新日期：2009-05-29T20:13:00Z
創建日期：2000-10-08T00:45:00Z
註冊到期日期：2010-10-08T00:44:59Z
註冊商註冊到期日期：2010-10-08T00:44:59Z11
註冊商：範例註冊商有限責任公司
註冊商IANA ID：5555555
註冊商濫用聯絡電子郵件：email@registrar.tld
註冊商濫用聯絡電話：+1.1235551234
轉售商：範例轉售商12
域名狀態：客戶刪除禁止
域名狀態：客戶續訂禁止
域名狀態：客戶轉移禁止 域名狀態：伺服器更新禁止
註冊庫註冊人ID：5372808-ERL
註冊人姓名：範例註冊人
註冊人組織：範例組織
註冊人地址：123範例街
註冊人城市：ANYTOWN
註冊人州/省：AP
註冊人郵遞區號：A1A1A1
註冊人國家：EX
註冊人電話：+1.5555551212
註冊人電話分機：1234
註冊人傳真：+1.5555551213
註冊人傳真分機：4321
註冊人電子郵件：EMAIL@EXAMPLE.TLD
註冊管理員ID：5372809-ERL
管理員姓名：EXAMPLE 註冊人管理
管理員組織：EXAMPLE 註冊人組織
管理員街道：123 EXAMPLE STREET
管理員城市：ANYTOWN
管理員州/省：AP
管理員郵政編碼：A1A1A1
管理員國家: EX
1 欄位為可選。
2 欄位為可選。
51
管理員電話: +1.5555551212
管理員電話分機: 1234
管理員傳真: +1.5555551213
管理員傳真分機:
管理員電子郵件: EMAIL@EXAMPLE.TLD 註冊技術 ID: 5372811-ERL
技術名稱：範例登記機構技術
技術機構：範例登記機構有限責任公司
技術街道：123範例街
技術城市：任何城鎮
技術州/省：AP
技術郵政編碼：A1A1A1
技術國家：EX
技術電話：+1.1235551234
技術電話分機：1234
技術傳真：+1.5555551213
技術傳真分機：93
技術電子郵件：EMAIL@EXAMPLE.TLD
名稱伺服器：NS01.EXAMPLEREGISTRAR.TLD
名稱伺服器：NS02.EXAMPLEREGISTRAR.TLD
DNSSEC：簽名授權
DNSSEC：未簽名
ICANN Whois不準確性投訴表格的網址： https://www.icann.org/wicf/
>>> WHOIS數據庫最近更新時間：2009-05-29T20:15:00Z <<<
1.6 註冊商資料
1.6.1 查詢格式: whois “註冊商 示例註冊商有限公司”
1.6.2 回應格式:
註冊商： 示例註冊商有限公司
地址： 1234 Admiralty Way
城市：馬里納德雷 省/州：加州
郵政編碼：90292
國家：美國
電話號碼：+1.3105551212
傳真號碼：+1.3105551213
電子郵件：registrar@example.tld
註冊商WHOIS伺服器：whois.example-registrar.tld
註冊商網址：http://www.example-registrar.tld 管理聯絡人：喬·註冊商
電話號碼：+1.3105551213
52
傳真號碼：+1.3105551213
電子郵件：joeregistrar@example-registrar.tld
管理聯絡人：Jane Registrar
電話號碼：+1.3105551214
傳真號碼：+1.3105551213
電子郵件：janeregistrar@example-registrar.tld
技術聯絡人：John Geek
電話號碼：+1.3105551215
傳真號碼：+1.3105551216
電子郵件：johngeek@example-registrar.tld
>>> WHOIS資料庫的最後更新：2009-05-29T20:15:00Z <<<
1.7 域名伺服器資料：
1.7.1 查詢格式：whois “nameserver (域名伺服器名稱)”，或whois “nameserver (IP地址)。”例如：whois “nameserver NS1.EXAMPLE.TLD”。
1.7.2 回應格式：
伺服器名稱：NS1.EXAMPLE.TLD
IP 地址：192.0.2.123
IP 地址：2001:0DB8::1
註冊商：Example Registrar, Inc.
註冊商 WHOIS 伺服器：whois.example-registrar.tld
註冊商網址：http://www.example-registrar.tld
>>> WHOIS 資料庫的最後更新：2009-05-29T20:15:00Z <<<
1.8 以下資料欄位的格式：域名狀態、個人及組織名稱、地址、街道、城市、州/省、郵遞區號、國家、電話及傳真號碼（擴展部分將根據上面所示作為單獨欄位提供）、電子郵件地址、日期及時間應符合在 EPP RFCs 5730-5734 中規定的映射，以便於該資訊（或在 WHOIS 回應中返回的值）的顯示可以統一處理和理解。
2. RDDS政策和教育材料. 登記運營商應在TLD的主網站上提供指向ICANN指定的網頁的鏈接，該網頁包含RDDS政策和教育材料。
3. 可搜索性. 提供通過RDDS提供的登記數據的可搜索性功能是可選的，但如果由登記運營商提供，則必須遵守本節中描述的規範。
3.1 登記運營商將提供作為基於網絡的服務的可搜索性。
53
3.2 登記運營商將在以下每個字段上提供部分匹配功能：域名、聯繫人和登記人的姓名，以及聯繫人和登記人的郵政地址，包括EPP中描述的所有子字段（例如，街道、城市、州或省等），並且可能在其他字段上提供部分匹配功能，每種情況均須遵守適用法律。
3.3 登記運營商將至少在以下字段上提供精確匹配功能：登記商ID、名稱伺服器名稱和名稱伺服器的IP地址（僅適用於登記處存儲的IP地址，即粘合記錄）。
3.4 登記運營商將提供布林搜索功能，支持至少以下邏輯運算符來連接一組搜索條件：AND、OR、NOt。
3.5 搜尋結果將包括符合搜尋標準的域名。
3.6 登記機構將：1) 實施適當措施以避免濫用此功能（例如，只允許合法授權用戶訪問）；及 2) 確保該功能遵守任何適用的隱私法及ICANN共識政策和臨時政策。
3.7 登記機構僅應提供RDAP技術實施指南和RDAP響應配置文件中所需的可搜索性功能，如附錄50億第2.1節所述。
4. 登記數據目錄服務 (RDDS) 要求. 自2024年12月1日起，登記機構應遵守 以下要求：
4.1. 登記機構應為其RDDS提供公共IPv6和IPv4傳輸。
4.2. 為確保TLD的權威信息保持公開可用，登記機構應向IANA功能運營商提交更改請求，以更新任何過時或不準確的DNS、WHOIS或RDAP基本URL，針對TLD的RDAP目錄服務記錄。登記機構應竭盡商業合理努力，在任何此類DNS、WHOIS或RDAP基本URL變得過時或不準確後的七（7）個日曆天內提交任何此類更改請求。登記機構必須根據https://www.iana.org/domains/root中列出的程序提交所有更改請求。
4.3. 註冊數據中包含的個人數據必須根據ICANN共識政策和臨時政策進行刪除。
4.4. 註冊機構必須遵循與一致標籤和顯示共識政策中額外字段相關的要求，如果註冊機構選擇添加數據字段。
54
4.5 在註冊數據目錄服務要求與共識政策或任何臨時政策之間發生衝突的情況下，共識政策或臨時政策應該優先適用，但僅限於衝突主題，並按照本協議第3.1(b)節（共識政策）進行。
4.6. 直至根據ICANN董事會在2019年5月通過的關於gTLD註冊數據的臨時規範的快速政策發展過程第一階段GNSO共識政策建議進行更新並生效為止，該政策中的以下條款將被解釋如下：
4.6.1 除“可搜索的Whois”和“Whois聯絡信息查詢服務”外，下列條款：“WHOIS”、“Whois”、“Whois服務”、“公開可訪問的Whois”及其變體應解釋為指本附錄中定義的RDDS。
4.6.2 “Whois數據”、“WHOIS信息”、“Whois聯絡信息”、“WHOIS查詢數據”、“WHOIS詳細信息”、“Whois輸出”、“Whois記錄”、“Whois條目”及其變體應解釋為指本附錄中引用的註冊數據。
4.7. 合作進行過渡研究. 如果ICANN啟動或委託一項關於WHOIS數據目錄服務轉向RDAP目錄服務的研究，註冊機構應合理配合該研究，包括向ICANN或其指定進行該研究的人員提供與其提供RDAP數據目錄服務的經驗相關的定量和定性數據。如果數據請求超出了註冊機構在正常業務中收集的範圍，以及超出了根據本協議註冊機構必須收集和提供給ICANN組織的數據，註冊機構應自願合作提供所請求的信息，或向ICANN解釋為何註冊機構無法提供所請求的信息。本條款並不要求註冊機構提供超出其根據本協議其他條款所需提供的數據給ICANN。根據本條款提供給ICANN或其指定方的任何數據，如果標註為機密，應被視為註冊機構的機密信息，前提是，儘管有本協議，如果ICANN或其指定方對該數據進行聚合並匿名化，ICANN或其指定方可以向任何第三方披露該數據。在註冊機構提供數據的過渡研究完成後，ICANN將銷毀根據本條款提供但未被聚合和匿名化的所有數據。
55
5. 大量註冊數據訪問ICANN
5.1 定期訪問薄註冊數據. 為了驗證和確保登記服務的運營穩定性，分析DNS的運營穩定性，並促進對認證註冊商的合規檢查和審計，登記運營商將每日向ICANN提供本節5.1所指定的最新註冊數據。數據將包括截至前一天的00:00:00 UTC所承諾的數據。每年，ICANN將發布利用該數據進行的研究項目的摘要，並列出共享原始數據以進行研究的任何組織。
5.1.1 內容. 登記運營商將為所有已註冊的域名提供以下數據：域名、域名存儲對象ID（roid）、註冊商ID（IANA ID）、狀態、最近更新日期、創建日期、到期日期和名稱伺服器名稱。對於贊助註冊商，登記運營商將提供：註冊商名稱、註冊商ID（IANA ID）、註冊商WHOIS伺服器的主機名稱（如果註冊商提供的話，將在2025年1月28日之後繼續提供）和註冊商的URL。登記運營商不得提供任何額外的數據元素。
5.1.2 格式. 數據將按照附錄1數據保險規範中規定的格式提供（包括加密、簽名等），但僅包括前面部分提到的字段，即該文件將僅包含具有上述字段的域和註冊商對象。
5.1.3 訪問. 登記管理者將於協調世界時間00:00:00準備好檔案供ICANN下載。檔案會透過SFTP提供下載，儘管ICANN將來可能會要求其他方式。
5.2 特殊方式訪問厚註冊數據. 本第5.2節僅在TLD以「厚」登記模型運作後適用（如有）。如果發生登記商失敗、取消認證、法院命令等情況，導致其域名暫時或永久轉移至另一家登記商，根據ICANN的要求，登記管理者將向ICANN提供失去登記商的域名的最新數據。這些數據將以附錄1數據保險規範中指定的格式提供。該檔案僅包含有關失去登記商域名的數據。登記管理者將在商業上可行的最短時間內提供數據，但不遲於ICANN要求後的五（5）個日曆天。除非登記管理者和ICANN另有協議，否則該檔案將以與本附錄第5.1節中指定的數據相同的方式向ICANN提供下載。
56
.com登記協議附錄5B
註冊數據訪問協議
服務規範
1範圍與定義.
1.1. [保留]
1.2. [保留]
1.3「註冊數據訪問協議」或「RDAP」是一種網際網路協議，提供「RESTful」網路服務，以從域名註冊機構和區域網際網路註冊機構檢索註冊元數據。
1.4.「RDAP目錄服務」或「RDAP-RDDS」指的是使用STD 95中描述的RDAP的註冊數據目錄服務（https://www.rfc-editor.org/refs/ref-std95.txt），以及其後續標準。
1.5.「RDAP查詢往返時間」指的是從RDAP-RDDS測試探針的TCP連接開始到結束的數據包序列的往返時間（「RTT」），包括僅對一個HTTPS請求接收HTTPS響應的時間。如果RTT達到或超過相應SLR/性能規範的5倍，則該RTT將被認為是未定義的。
1.6.「RDAP可用性」指的是RDAP-RDDS服務對於頂級域名（TLD）能夠對來自網際網路使用者的查詢作出回應，並提供相關註冊系統的適當數據。如果51%或以上的RDAP測試探針在特定時間內發現RDAP-RDDS服務為不可用，則該服務將被視為未回應。
1.7.「RDAP更新時間」指的是從收到域名、主機或聯繫人的EPP確認到轉換命令的時間，直到至少51%可檢驗的RDAP-RDDS測試探針檢測到所做的變更。
2. RDAP目錄服務。
2.1註冊機構應實施最新版本的RDAP技術實施指南和RDAP響應檔，該檔已張貼於https://icann.org/gltd-rdap-profile。註冊機構將在收到ICANN的通知後不超過一百八十（180）個日曆日內實施RDAP技術實施指南和RDAP響應檔的新版本。
57
2.2 登記運營商應提供查詢支持以進行：
2.2.1 如RFC 9082的「域名路徑段規範」所述的域名資訊。
2.2.2 如RFC 9082的「名稱伺服器路徑段規範」所述的名稱伺服器資訊；但是，登記運營商不必（但仍可以選擇）支持名稱伺服器查詢，如果登記運營商在EPP中將名稱伺服器指定為域名屬性。
2.2.3 如RFC 9082的「實體路徑段規範」所述的註冊商資訊。
2.2.4 如RFC 9082的「幫助路徑段規範」所述的幫助資訊。
3. 服務水平要求。 登記運營商必須符合以下每一項服務水平要求：
3.1. 服務水平要求矩陣
| 參數 | 服務水準要求 (SLR)/執行規範 (每月基準) | |||||||
| RDAP-RDDS | RDAP 可用性 | ≦ 864分鐘的停機時間 (98%) | ||||||
RDAP 查詢RTT | ≦ 4000毫秒，對於至少95%的查詢 | |||||||
| RDAP更新時間 | ≦ 60分鐘，對於至少95%的更新 | |||||||
3.2.登記運營商應監測並測量其RDAP-RDDS服務水平要求的性能，該要求在上述第3.1節中列出，使用登記運營商的
58
監測探針，僅用於：(a) 確定登記運營商在為登記機構計算SLA信貸時的RDAP-RDDS服務性能（如有）；以及(b) 按照附錄4第1節（服務水平協議績效報告）向ICANN提供RDAP服務水平要求的績效數據。
3.3.登記運營商鼓勵在每個參數統計較低的流量時間和日期進行RDAP的維護。然而，並不提供計劃停機或類似的不可用期間；任何停機時間，無論是因維護還是由於系統故障，將僅被記錄為停機，並計入服務水平要求的測量目的中。
3.3.1 若登記運營商計劃RDAP維護，必須提前至少二十四（24）小時通知ICANN緊急操作部門。ICANN的緊急操作部門將記錄計劃的維護時間，並在預期的維護停機期間暫停監控服務的緊急升級服務。
3.4.對於未能滿足第3.1節中規定的RDAP服務水平要求的補救辦法，應等同於本協議中對於未能滿足WHOIS服務相應性能規範的補救辦法，然而，在某一月份RDAP-RDDS服務和WHOIS服務都失效的情況下，適用的SLA信用，對於登記機構不應超過因WHOIS服務的服務水平要求失效而單獨產生的SLA信用的總額，根據登記機構運營者的協議。.
3.5.[保留]。
3.6.各方同意上述第3.4節中描述的SLA信用為對登記機構運營者的總信用、罰款和/或責任，並且是登記機構在登記機構運營者未能滿足RDAP-RDDS服務的服務水平要求時唯一的救濟方式。
3.7.登記機構運營者將在不可抗力事件結束後24小時內，使用商業合理的努力恢復RDAP-RDDS服務功能。由於不可抗力造成的中斷將不被視為附錄7或服務水平要求下的服務不可用。
3.8.如果登記機構運營者因遵守任何共識政策而未能滿足RDAP-RDDS服務的服務水平要求，則對ICANN或登記機構不承擔任何信用或罰款的責任，或不被視為違反本協議下的任何義務。
59
在有效日期之後建立的共識政策的範圍內及在繼續滿足該共識政策下，未能滿足RDAP-RDDS服務的服務水平要求在商業合理的努力下是不可避免的情況下。
3.9.本附件第3節中列出的RHAD-RDDS服務的服務水平要求及附件第4.5節中列出的RDAP測量參數將被視為「性能規範」，而「RDAP-RDDS」服務將被視為本協議目的下的「系統服務」，並應視為附錄7中的規定。
3.10.為了確定由於登記機構未能滿足服務水平要求而導致的SLA信用的適當信用水平和計算，信用水平和計算應根據下表中列出的相應參考以及本協議進行。
RDAP-RDDS服務水平要求 | 計算SLA信用水平的相應參考 信用 | ||||
RDAP可用性 | 服務可用性--Whois | ||||
RDAP查詢RTT | 處理時間--Whois查詢 | ||||
RDAP更新時間 | 更新頻率--Whois | ||||
3.11. 在部分投資組合收購後的批量轉移中，根據附錄7第8.1節的通知要求，失去的登記管理機構應提供一個描述，即RDDS記錄在此類批量轉移發生後將如何變更。
4. RDAP測量參數.
4.1. RDAP測試. 意味著發送到RDAP-RDDS服務器之一的特定IP地址的單一查詢。查詢應該是關於登記系統中存在的對象，且響應必須包含相應的信息，否則該查詢將被視為未答復。RTt超過相應SLR 5倍的查詢將被視為未答復。RDAP測試的可能結果為：以毫秒為單位的數字，對應於RDAP查詢的RTt或未答復。
4.2. 測量RDAP參數. 每五分鐘，RDAP-RDDS探針將從被監控的TLD的RDAP-RDDS服務器的所有公共DNS註冊“IP地址”中選擇一個IP地址並進行“RDAP測試”。如果RDAP測試結果未答復，則相應的RDAP-RDDS服務將被視為該探針不可用，直到進行新的測試。
60
4.3. 匯總來自RDAP-RDDS探針的結果在任何給定的測量期間，考慮測量有效的最低活躍測試RDAP-RDDS測試探針數量為10個，否則測量將被丟棄並被視為「不確定」；在此情況下，不會對SLR標記任何故障。
4.4. RDAP-RDDS探針的安置. ICANN將用商業上合理的努力在ICANN的每個地理區域內的數據中心中部署用於測量RDAP參數的探針，並具有運營商級的連接性。
4.5. 無干擾註冊機構不得干擾測量探針，包括對受監視服務請求的任何形式的優待。註冊機構應以對互聯網用戶的任何其他RDAP請求的方式回應本附件中描述的測量測試。
4.6. 緊急升級. 註冊機構和ICANN應向對方提供各自緊急操作部門的聯絡信息，以便於本條款的目的，並且註冊機構和ICANN應始終保持並更新該聯絡信息。ICANN應發出緊急升級通知，告知註冊機構有關監測的RDAP-RDDS服務的任何可能或潛在問題。在發出緊急升級通知後，註冊機構和ICANN應協作並用商業上合理的努力診斷和/或解決識別出的問題，包括通過共享適當的測量數據。任何緊急升級的啟動及隨後協作以診斷和/或解決識別出的問題本身並不暗示或以其他方式確立被監測的RDAP-RDDS服務未能滿足上述第3.1節所設置的服務水平要求。
5. ICANN保留通過適用的IETF流程，對附錄5A和附錄50億中提到的註冊數據指定作為“網際網路標準”（與資訊性或實驗性標準相對）的替代格式和協議的權利。在如此規範之後，ICANN應： (a) 與登記管理人及其他gTLD登記處和ICANN認證的登記商協作，定義實施適用標準所需的所有操作要求；(b) 如適用，與登記管理人展開談判，以定義所有報告要求（如有），以及根據類似服務的合理服務水平要求，並適用於TLD。
61
.com登記協議附錄6
保留名稱清單
除非ICANN以書面形式明確授權，否則登記管理人應保留以下標籤形成的名稱，並禁止其在TLD內進行初始（即非續期）註冊：
A. 所有層級保留的標籤。 以下名稱應在第二級及登記管理人進行註冊的TLD內所有其他層級保留：
ICANN相關名稱：
•aso
•gnso
•icann
•internic
•ccnso
IANA相關名稱：
•afrinic
•apnic
•arin
•範例
•gtld-伺服器
•iab
•iana
•iana-伺服器
•iesg
•ietf
•irtf
•istf
•lacnic
•latnic
•rfc-editor
•ripe
•root-servers
b. 其他第二級保留名稱. 此外，以下名稱應在第二級保留:
•所有單字符標籤。儘管有此保留，單字符標籤o.com仍可根據o.com服務（定義於附錄7，第8.2條）釋放。
•所有雙字符標籤最初將被保留。當登記機構與政府和國家碼管理機構或ISO 3166維護機構（適用者）達成協議時，雙字符標籤字符串的保留將被釋放。登記機構還可以根據其實施的措施提議釋放這些保留，以避免與相應的國家碼造成混淆。
62
C. 標記的域名。 所有第三和第四字符位置中帶有連字符的標籤（例如，"bq--1k2n4h4b"或"xn--ndk061n"）
D. 登記操作的第二級保留。 以下名稱被保留用於登記機構對登記頂級域的運營。這些名稱可以由登記機構使用，但在登記機構被指定為登記頂級域的運營商後，應根據ICANN指定的方式進行轉移：
•nic
•whois
•www
63
.com 註冊協議附錄 7
功能和性能規範
這些對於註冊 TLD 的功能規範包含以下部分：
1. 註冊管理員與登記機構的協議；
2. 支持的初始和續期註冊期間；
3. 寬限期政策；
4. 名稱伺服器功能規範；
5. 修補、更新和升級政策；
6. 性能規範；
7. 各方責任；
8. 其他服務；及
9. 新標準的實施
1. 註冊管理者註冊商協議
1.1 可擴展配置協議
註冊管理者應按提議標準和信息性RFC 5730、5731、5732、5734、5910和3915的要求維護可擴展配置協議（"EPP"）（如註冊管理者接受厚註冊數據RFC 5733），該標準由互聯網工程任務組（"IETF"）發佈，及/或其任何繼任標準、版本、修改或註解，註冊管理者認為合理必要的。註冊管理者將按上述標準支持EPP。如果註冊管理者需要使用EPP RFC以外的功能，則必須使用根據RFC 3735中描述的指導方針，按照網際草案格式記錄EPP擴展。註冊管理者無需將記錄的EPP擴展提交給IETF，但需要考慮RFC 3735第2.1節中描述的標準化建議。註冊管理者將在部署之前向ICANN提供和更新所有EPP對象及支持的擴展的相關文件。
登記運營商應能接受IPv6地址作為其登記系統中的粘貼記錄，並在DNS中發佈這些記錄。登記運營商應在收到希望在IPv6上運作共享登記系統（SRS）的gTLD認證登記商的首個書面請求後不超過六個月，向任何登記商提供公共IPv6傳輸。
當提供書面證據顯示這些記錄與惡意行為有關時，登記運營商應採取行動以移除孤立的粘貼記錄（定義詳見http://www.icann.org/en/committees/security/sac048.pdf）。
2. 支持的初始及續期登記期限
2.1. 註冊的名稱的初始登記（根據功能規範和其他要求可用時）可在登記處進行，期限最多為十年。
64
2.2. 註冊的名稱的續期登記（根據功能規範和其他要求可用時）可在登記處進行，期限不得超過總共十年。
2.3. 根據ICANN關於登記商之間登記轉移政策的A部分，當註冊的名稱的贊助變更從一個登記商變更為另一個登記商時，該註冊的名稱的登記期限將延長一年，前提是至贊助變更生效日的登記最大期限不超過十年。
2.4. 根據ICANN關於登記商之間登記轉移政策的B部分，註冊的名稱從一個登記商變更為另一個登記商的贊助變更將不會導致登記期限的延長，登記運營商可以協助此類贊助變更。
3. 寬限期政策
本節描述登記運營商在操作「寬限期」和「待處理」期間的做法，包括在特定時間範圍內發生的連續操作之間的關係。 寬限期限 「寬限期」指的是在登記操作之後的特定日曆天數，在此期間域名操作可以被撤回，並可能對註冊商發放信貸。與此相關的登記操作包括：
•新域名的註冊，
•現有域名的續訂，
•現有域名的自動續訂；
•現有域名的轉移；以及
•現有域名的刪除。
註冊期間的延長是通過EPP RENEW命令或自動續訂來實現的；註冊是通過EPP CREATE命令來完成的；刪除/移除是通過EPP DELETE命令來實現的；轉移是通過EPP TRANSFER命令或在ICANN根據ICANN登記商之間的註冊轉移政策第b部分批准批量轉移的情況下，使用該部分中指定的程序來完成的。恢復是通過EPP UPDATE命令來實現的。
登記管理機構的共享註冊系統提供了五個寬限期： 新增寬限期、續訂/延長寬限期、自動續訂寬限期、轉移寬限期和贖回寬限期.
A 待處理期間 指的是在登記操作之後特定的日曆天數，在此期間最終登記行動被延遲，直到操作完成。在這個上下文中，相關的登記操作是：
•轉移現有域名，
•刪除現有域名，和
65
•在贖回寬限期內恢復域名。
3.1. 寬限期
3.1.1 新增寬限期
The 新增寬限期 是在註冊域名後的一定天數內的日曆天數。當前的 新增寬限期 對於所有註冊商來說，寬限期為五個日曆天。如果在這五個日曆天內發生刪除、延長（EPP 更新命令）或轉移操作，則適用以下規則：
刪除。 如果一個域名在 添加寬限期，在刪除時的贊助註冊商將獲得註冊金額的信用；不過，註冊管理運營商有權根據其註冊管理－註冊商協議對於不成比例的刪除收取費用。 添加寬限期。該域名已從註冊庫數據庫中刪除，並立即可供任何註冊商註冊。請參閱第3.2節以了解重疊寬限期例外的描述。
延長（EPP續訂命令）。 如果一個域名在 添加寬限期內延長對於該增項，並無任何信用。域名註冊的到期日會依照註冊商要求的延長操作延長若干年，最多可延長至十年。
轉移（不包括ICANN認可的大宗轉移）。 根據ICANN轉移註冊商之間註冊的政策A部分的轉移，在以下期間內不得進行轉移， 增項寬限期 或在初次註冊後的前60天內的任何其他時間。執行責任由贊助域名註冊的註冊商負責，並由SRS執行。
大宗轉移（需ICANN批准）。 在ICANN批准的大宗轉移中， 增項寬限期 根據ICANN有關註冊商之間轉讓註冊的政策第b部分的程序，轉讓註冊的到期日期不受影響。失去的註冊商的帳戶會因初始新增而收費。
3.1.2. 續費/延長寬限期
The 續費/延長寬限期 是在通過EPP命令續約的域名註冊期續費/延長後的一定數量的日曆天。當前的 續費/延長寬限期 為五個日曆天。如果在這五個日曆天內發生刪除、延長或轉讓，則適用以下規則：
刪除。 如果一個域名在「 續期/延長寬限期」內被刪除，當時的註冊商會收到續期/延長費用的信用。該域名會立即進入贖回寬限期。請參見第3.2節了解重疊寬限期例外的描述。
延長（"EPP命令 '續期'"）。 一個域名可以在「 續期/延長寬限期 」內延長最多十年。當時的註冊商帳戶將被收取額外延長的年份的費用。
轉移（除ICANN批准的批量轉移外）。 如果域名在此期間轉移， 續訂/延長寬限期兆.在此期間沒有信用。域名註冊的到期日延長一年，由於延長而添加的年份在總計不超過10年內保留在域名上。
66
批量轉移（經ICANN批准）。經ICANN批准的批量轉移可在 續訂/延長寬限期 按照ICANN關於註冊商之間註冊轉移政策的第b部分的程序進行。轉移的註冊的到期日期不受影響。失去的註冊商的帳戶將收取續訂/延長操作的費用。
3.1.3 自動續訂寬限期
The 自動續訂寬限期 是指在自動續訂後的一定天數內。在域名註冊在到期日之前未續訂的情況下，將會進行自動續訂；在這種情況下，系統會在到期日的翌日自動續訂該註冊。當前的 自動續訂寬限期 為45天。如果在 自動續訂寬限期內進行刪除、延長或轉移，則適用以下規則：
刪除。 如果在 自動續訂寬限期在刪除時，贊助的登記機構將獲得自動續訂費用的信用。該域名會立即進入贖回寬限期。詳情請參見第3.2節，有關重疊寬限期例外的描述。
延長。 域名可以在 自動續訂寬限期 內延長最多十年。在額外延長時，贊助的登記機構帳戶將按延長的年數收取費用。
轉移（除了ICANN批准的大宗轉移）。 如果域名在 自動續訂寬限期失去的註冊商將獲得自動續訂的收費，並且由自動續訂操作新增的一年會被取消。域名的到期日期延長一年，最多可達十年，而獲得的註冊商將為這額外的一年收取費用，即使因為十年註冊期限的最大限制，並未添加完整的一年。
批量轉移（經ICANN批准）. 經ICANN批准的批量轉移可以在 自動續訂寬限期 根據ICANN註冊商之間轉移註冊政策第b部分的程序進行。轉移註冊的到期日期不受影響。失去的註冊商賬戶將被收取自動續訂的費用。
3.1.4. 轉移寬限期
The 轉移寬限期 是根據ICANN註冊商之間轉移註冊政策第A部分所規定的，跟隨域名轉移後的特定日曆天數。當前的值為 轉移寬限期 為五個日曆天。如果在這五個日曆天內發生刪除、延長或轉移，則適用以下規則：
刪除。 如果域名在 轉移寬限期內被刪除，則刪除時的贊助註冊商將獲得轉移費用的信用。該域名立即進入贖回寬限期。請參閱第3.2節，了解重疊寬限期例外的描述。
延長。 如果在 轉移寬限期內延長了域名註冊，則不會有轉移貸款。註冊商的帳戶將根據延長的年份數收費。域名註冊的到期日期將根據年份數延長，最多可延長十年，具體由註冊商所請求的延長操作所規定。
67
轉移（除了ICANN批准的批量轉移）。 如果在 轉移寬限期內轉移域名，則不會有貸款。域名註冊的到期日期將延長一年的時間，最多可延長十年。ICANN關於註冊商之間域名轉移的政策不允許在發生其他轉移後的前60天內進行轉移；此項限制的執行由註冊商負責。
批量轉移（經ICANN批准）。 經ICANN批准的批量轉移可以在 轉移寬限期 根據ICANN關於註冊商之間註冊轉移政策的第b部分的程序進行。轉移的註冊的到期日期不受影響。失去的註冊商賬戶會因批量轉移之前發生的轉移操作而收費。
3.1.5. 批量轉移寬限期
批量轉移操作不會有寬限期。批量轉移完成後，任何相關費用將不予退還。
3.1.6 恢復寬限期
當註冊商請求刪除一個不在添加寬限期內的域名時，該域名會被放置在恢復寬限期狀態。處於恢復寬限期狀態的名稱將不會包含在區域文件中。註冊商不能修改或移除處於恢復寬限期狀態的域名。註冊商對於處於恢復寬限期的域名唯一能執行的操作是請求其恢復。其他註冊商的請求以修改或以其他方式更新域名將被拒絕。除非恢復，否則該域名將在恢復寬限期狀態下保留指定的日曆天數。目前此恢復期的長度為30個日曆天。
3.2. 重疊的寬限期
如果執行的操作落入多個寬限期，則適用於每個寬限期的行動（根據下述的某些例外情況）。
•如果一個域名在新增寬限期和延長寬限期內被刪除，那麼登記商將獲得註冊和延長金額的信用，考慮到註冊和延長的年數。
•如果一個域名自動續訂，然後延長，然後在延長寬限期內被刪除，則登記商將獲得任何收取的自動續訂費用的信用以及延長的年數。
3.2.1. 重疊例外
•如果在轉移寬限期內延長域名註冊，那麼當前登記商的帳戶將根據註冊延長的年數收費。
備註: 如果在一個域名上執行多個可計費操作，包括轉移，並且該域名在這些操作的每個寬限期內被刪除，那麼僅那些在最新轉移後執行的操作，包括最新轉移，會被計入當前登記商。
68
3.3. 等待轉移期
3.3.1. 轉移等待期
The 轉移等待期 是指在域名的現任註冊機構（註冊機構B）收到來自另一註冊機構（註冊機構A）請求轉移的要求後，針對該域名的指定日曆天數，在此期間，現任註冊機構可以明確批准或拒絕該轉移請求。當前的 轉移等待期 對所有註冊機構來說為五個日曆天。該轉移將在收到現任註冊機構（註冊機構B）的明確批准或拒絕後最終確定。如果現任註冊機構（註冊機構B）未明確批准或拒絕註冊機構A發起的請求，則註冊機構運營商將在 轉移等待期結束後，自動批准請求。。在 轉移待處理期間:
a. EPP 轉移請求或 EPP 續期請求被拒絕。
b. 不允許同步。
c. EPP 刪除請求被拒絕。
d. 允許批量轉移操作。
e. EPP 更新請求被拒絕。
b. 不允許同步。
c. EPP 刪除請求被拒絕。
d. 允許批量轉移操作。
e. EPP 更新請求被拒絕。
在轉移一個域名後，EPP 轉移請求可能會被拒絕 60 天。
3.3.2. Pending Delete Period
A domain name is placed in PENDING DELETE status if it has not been restored during the Redemption Grace Period. A name that is in PENDING DELETE status will not be included in the zone file. All Registrar requests to modify or otherwise update a domain in PENDING DELETE status will be rejected. A domain name is purged from the registry database a specified number of calendar days after it is placed in PENDING DELETE status. The current length of this Pending Delete Period is five calendar days.
4. Nameserver functional specifications
Nameserver operations for the Registry TLD shall comply with RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966 published by the Internet Engineering Task Force ("IETF") and/or any successor standards, versions, modifications or additions thereto.
Registry Operator shall sign its TLD zone files implementing Domain Name System Security Extensions ("DNSSEC"). Registry Operator shall comply with RFCs 4033, 4034, 4035, 4509 and their successors, and the parties agree that best practices described in RFC 4641 and its successors are recommended but not mandatory. If Registry Operator implements Hashed Authenticated Denial of Existence for DNS Security Extensions, it shall comply with RFC 5155 and its successors. Registry Operator shall accept public-key material from child domain names in a secure manner according to industry best practices. Registry shall also publish in its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants' public-key material. Registry Operator shall publish its DPS following the format described in RFC 6841.
Registry Operator shall offer public IPv6 transport for, at least, two of the Registry's name servers listed in the root zone with the corresponding IPv6 addresses registered with IANA. Registry Operator should follow "DNS IPv6 Transport Operational Guidelines" as described in BCP 91 and the recommendations and considerations described in RFC 4472.
69
對於未註冊的域名，或者註冊人未提供有效記錄（例如，用於在DNS區域檔案中列出的NS記錄），或者其狀態不允許它們在DNS中公開的域名，禁止使用如RFC 1034和4592所述的DNS通配符資源記錄，或以其他方法或技術合成DNS資源記錄，或由註冊運營商在DNS中進行重定向。當查詢此類域名時，權威名稱伺服器必須返回"名稱錯誤"響應（也稱為NXDOMAIN），RCODE 3，如RFC 1035及相關RFC所述。此條款適用於註冊運營商（或從事提供註冊服務的附屬機構）維護數據、安排此類維護或從此類維護中獲利的DNS樹中所有層級的所有DNS區域檔案，但此條款不適用於單一實體（包括其附屬機構）對於通過ICANN認可的註冊商註冊的域名或區域，用於非註冊服務的名服務或任何其他非註冊服務。
如果註冊運營商提供國際化域名（"IDNs"），則必須遵守RFC 5890、5891、5892、5893及其後續版本。註冊運營商應遵守https://www.icann.org/en/topics/idn/implementation-guidelines.htm中的ICANN IDN指導方針，這些方針可能會不時修訂、修改或取代。註冊運營商應在IANA IDN實踐庫中發布並保持更新其IDN表和IDN註冊規則。
5. 補丁、更新和升級政策
註冊運營商可以向根據註冊-註冊商協議（"協議"）授權的軟體、EPP或API（"授權產品"）發佈定期的補丁、更新或升級，以增強功能或以其他方式改善根據協議的共享註冊系統。根據附錄7的第5條，本條款中所涉的術語具有以下所述的相關含義。
5.1 "修補程式" 指的是由登記機構在執行錯誤更正服務期間對授權產品所做的輕微修改。修補程式不構成版本。
5.2 "更新" 指的是授權產品的新版本，可能包含錯誤更正、輕微增強，並且在某些情況下包含重大增強，以版本號中小數點右側的數字變化來表示。
5.3 "升級" 指的是授權產品的新版本，涉及新增實質或大幅增強的功能，以版本中小數點左側的數字變化來表示。
5.4 "版本" 指的是由任何單一版本號識別的授權產品。
每次更新和升級都會導致版本變更。
* 修補程式不需要對每個登記機構開發、實施和維護的客戶應用程序進行相應的更改。
* 更新可能需要每個登記機構對客戶應用程序進行更改，以便利用新特性和/或功能，並繼續訪問共享註冊系統。
* 升級需要每個登記機構對客戶應用程序進行更改，以便利用新特性和/或功能，並繼續訪問共享註冊系統。
* 修補程式不需要對每個登記機構開發、實施和維護的客戶應用程序進行相應的更改。
* 更新可能需要每個登記機構對客戶應用程序進行更改，以便利用新特性和/或功能，並繼續訪問共享註冊系統。
* 升級需要每個登記機構對客戶應用程序進行更改，以便利用新特性和/或功能，並繼續訪問共享註冊系統。
70
登記運營商可自行決定在預定和公告的共享註冊系統維護期間部署補丁。
對於更新和升級，登記運營商將在將更新和升級部署到生產環境之前，提前通知每個註冊商。通知須至少提前九十（90）天。該通知將包括在部署需要更改客戶應用程序的更新之前的初步通知，以及將升級部署到所有註冊商均可訪問的運行測試與評估（"OT&E"）環境。登記運營商將在OT&E環境中維持更新或升級至少三十（30）天，以便每個註冊商有機會修改其客戶應用程序並完成測試，然後再在生產環境中實施新代碼。
如果登記運營商的系統面臨即將發生的故障或重大安全威脅、大型安全漏洞的發現，或拒絕服務（DoS）攻擊導致登記運營商的系統無法訪問，則本通知期限將不適用，這些情況包括：
i) 過量的數據流量
ii) 未經授權的流量
iii) 不符合登記使用的協議的數據流量
ii) 未經授權的流量
iii) 不符合登記使用的協議的數據流量
6. 性能規範
這些性能規範提供了一種衡量登記運營商交付SRS、DNS名稱伺服器和Whois服務的方式，並作為服務水平協議信用的基礎（"SLA信用）詳列於附錄10。
6.1 定義。 本第6節中使用的專有名詞，如未另有定義，應具備在登記協議中賦予的含義。
6.1.1 "核心網際網路服務故障" 是指超出登記運營商控制範圍的特殊且可識別的事件，影響本第6節所需測量的網際網路服務。此類事件包括但不限於擁擠崩潰、分區、電網故障和路由故障。
6.1.2 "信用等級" 指附錄10第2節中的表格SLA信用所列的信用等級，該表概述了可能對登記運營商施加的總信用、罰金和/或責任，以及ICANN認可的登記機構因登記運營商未能達到本附錄7中概述的性能規範而可用的唯一救濟措施。
6.1.3 "DNS名稱伺服器" 指符合RFC 1034、1035及相關RFC的服務，並在登記機構選定的伺服器上於TCP/UDP端口53上提供。
6.1.4 "ICANN認證的註冊商" 指與登記機構生效的登記-註冊協議的ICANN認證的註冊商。
6.1.5 "每月時間框架" 指每個從0000協調世界時（UTC）開始和結束的單獨日曆月份。
6.1.6 "性能規範" 指特定系統服務的可測量功能屬性的描述。
71
6.1.7 "註冊社群" 指所有與登記運營商簽訂登記-註冊協議並在前三十（30）個日曆期間註冊超過150個淨新.com網域名稱的ICANN認可的註冊商。
6.1.8 "往返" 指從SRS網關出發，通過SRS系統，再返回到SRS網關所需的完整查詢所測量的時間。
6.1.9 "服務水平協議（SLA）" 指附於登記協議附錄第10的服務水平協議，概述了性能標準級別。
6.1.10 "SRS" 指共享註冊系統，登記運營商通過定義的協議（EPP）為註冊商社群提供的系統，以進行登記和註冊之間的交互。具體而言，它指的就是ICANN認可的註冊商能夠新增、修改和刪除（創建、更新和刪除）與已註冊網域名稱及其相關DNS名稱伺服器相關的信息的能力。
6.1.11 "系統服務" 是指針對該註冊機構TLD所建立的可用性和性能規範的SRS、DNS名稱伺服器和Whois服務。
6.1.12 "Whois" 是指根據附錄5A提供的註冊機構運營商的Whois服務。
6.2 服務可用性。 服務可用性定義為註冊機構運營商的系統服務各自單獨回應其用戶的時間（"服務可用性"）如第6.2.1至6.2.4節所進一步定義。
6.2.1 服務可用性 可用性測量如下：
服務可用性 % = {[(MTm - POMU) - UOM] / (MTm - POMU)}*100 其中：
MTm = 每月時間框架分鐘數，計算方式為該月份的天數乘以24小時再乘以60分鐘。例如，1月份的MTm為31天 * 24小時 * 60分鐘，即MTm = 44,640分鐘。
POMU = 預定停機分鐘數，等於該月時間框架內每個系統服務的預定停機分鐘數（如以下第6.3節定義）或延長預定停機（如以下第6.4節定義）。每個月的時間框架內不得同時存在預定和延長預定停機。
UOm = 未計劃停機分鐘等於系統服務不可用的總分鐘數，不包括任何計劃停機（如下面第6.3節所定義）或延長計劃停機（如下面第6.4節所定義）在該月度時間範圍內。
服務可用性計算將由登記機構進行，並在每個月度時間範圍內報告SRS、Whois和DNS名稱伺服器的可用性結果。針對按日曆年測量的服務可用性性能規範，應用每年時間範圍分鐘（YTM）來替代上述計算中的每月時間範圍分鐘（MTM）。每年時間範圍分鐘計算為365天 * 24小時 * 60分鐘 = 525,600分鐘。結果將通過電子郵件報告給註冊商社群，並根據附錄4報告給ICANN。
6.2.2 服務可用性--SRS = 每年99.99%。 服務可用性在SRS中是指SRS能夠響應通過EPP協議訪問SRS的ICANN認可註冊商的能力。SRS不可用，除了計劃停機（如
72
下面第6.3節所定義）和延長計劃停機（如第6.4節所定義），將被記錄為登記機構的未計劃停機分鐘。不可用性不包括影響個別ICANN認可註冊商的事件。
SRS不可用性在SRS中將表示，由於登記機構控制範圍內系統的故障，ICANN認可註冊商無法與SRS網關建立會話；但前提是，SRS不可用性不包括ICANN認可註冊商因超過其指定的會話數而無法與SRS網關建立會話。與SRS網關建立會話將定義為：
a) 成功完成TCP會話啟動，
b) 成功完成SSL或TLS身份驗證握手，
成功完成可擴展配置協議（EPP）登錄命令。
當ICANN認可的註冊商以註冊管理員要求的方式（即電子郵件、傳真、電話）報告事件給註冊商客戶服務幫助台時，註冊運營商將記錄SRS不可用。SRS的承諾服務可用性為每年99.99%。SRS服務可用性指標為信用等級2。
6.2.3 服務可用性 - DNS名稱伺服器 = 每月時間框架100%。 就DNS名稱伺服器而言，服務可用性指的是DNS名稱伺服器解決來自互聯網用戶的DNS查詢的能力。DNS名稱伺服器的不可用將被記錄為註冊運營商的非計劃停機分鐘。當監控工具檢測到此類不可用性時，註冊運營商將記錄DNS名稱伺服器的不可用情況；或者一旦ICANN認可的註冊商以註冊管理員要求的方式（即電子郵件、傳真、電話）報告事件，並且註冊運營商確認該事件不是僅針對報告註冊商的情況。
DNS名稱伺服器不可用應指在註冊運營商的星系中返回查詢回答的站點少於八（8）個，且在每月時間框架內平均丟包率低於1%或在任何五分鐘的期間內丟包率達到5%。
DNS名稱伺服器的承諾服務可用性為每月時間框架100%。DNS名稱伺服器服務可用性指標為信用等級1。
6.2.4 服務可用性 - Whois = 每月時間框架100%。 就Whois而言，服務可用性指的是互聯網用戶訪問和使用Whois的能力。Whois不可用，除了計劃停機（如第6.3節所定義）和擴展計劃停機（如第6.4節所定義）將被記錄為註冊運營商的非計劃停機分鐘。註冊運營商將記錄Whois的不可用性（a）當此類不可用性被註冊運營商的監控工具檢測到，或（b）當ICANN認可的註冊商以註冊管理員要求的方式（即電子郵件、傳真、電話）報告事件時。Whois的承諾服務可用性為每月時間框架100%。Whois服務可用性指標為信用等級2。
6.3 預定停機。 註冊機構不時需要停機進行常規維護或增加新功能或特性（"預定停機").
73
6.3.1 預定停機持續時間。 預定停機持續時間定義了註冊機構可允許的最大時間，以分鐘計，讓系統服務中斷以進行定期計劃的維護（"預定停機持續時間）。預定停機會提前計劃，並在停機前向登記機構社群發出通知。
系統服務的預定停機持續時間如下：
(i) 計劃停機時間 - SRS = 每月時間框架45分鐘;
(ii) 計劃停機時間 - DNS名稱伺服器 = 不允許計劃停機; 以及
(iii) 計劃停機時間 - Whois = 不允許計劃停機。
計劃停機時間指標是信用等級6。
6.3.2 計劃停機時間框架。 計劃停機時間框架定義了計劃停機可能發生的小時和天數（"計劃停機時間框架"）系統服務的計劃停機時間框架如下:
(i) 計劃停機時間範圍 - SRS = 0100-0900 UTC 星期日;
(ii) 計劃停機時間範圍 - DNS 名稱伺服器 = 不允許計劃停機; 以及
(iii) 計劃停機時間範圍 - Whois = 不允許計劃停機。
計劃停機時間範圍的指標為信用等級 5。
6.3.3 計劃停機通知。 登記機構應通知所有ICANN認證的登記商任何計劃停機（"計劃停機通知"）計劃停機通知應列出計劃停機的日期和時間。登記機構應提前幾天通知登記商社群，具體如下:
(i) 計劃停機時間框架 - SRS = 30天進行一般維護，90天進行根據本附件第7節的修補、更新和升級政策所定義的更新或升級；
(ii) 計劃停機時間框架 - DNS名稱伺服器 = 不允許進行計劃停機；以及
(iii) 計劃停機時間框架 - Whois = 不允許進行計劃停機。
計劃停機通知指標為信用等級5。
6.4 延長計劃停機。 在某些情況下，例如重大軟體升級和平台更換，需要延長維護時間框架（"延長計劃停機"）延長計劃停機的頻率將低於計劃停機，但其持續時間可能更長。
6.4.1 延長計劃停機持續時間。 延長計劃停機持續時間定義了登記運營商允許將系統服務停用以進行延長維護的最大時間，按小時和分鐘計算（"延長計劃停機持續時間延長計劃停機是提前計劃的，並根據第6.4.3條款向登記商社區提供通知。延長計劃停機期間不得在與計劃停機相同的每月時間範圍內發生。系統服務的延長計劃停機持續時間如下：
(i) 延長計劃停機持續時間 - SRS = 每曆年4小時（240分鐘），每3年有一次8小時（480分鐘）的延長計劃停機；
74
(ii) 延長計劃停機持續時間 - DNS名稱伺服器 = 不允許延長計劃停機；
(iii) 延長計劃停機持續時間 - Whois = 不允許延長計劃停機。
延長計劃停機持續時間指標為信用等級6。
6.4.2 擴展計劃停機時間框架。 擴展計劃停機時間框架定義了擴展計劃停機可能發生的時間和日期（"擴展計劃停機時間框架）。系統服務的擴展計劃停機時間框架如下：
(i) 擴展計劃停機時間框架 - SRS = 0100 - 1300 UTC 星期日；
(ii) 擴展計劃停機時間框架 - DNS名稱伺服器 = 不允許擴展計劃停機；以及
(iii) 擴展計劃停機時間框架 - Whois = 不允許擴展計劃停機。
擴展計劃停機時間框架指標為信用等級5。
6.4.3 擴展計劃停機通知。 登記機構必須通知登記社群任何擴展計劃停機（"擴展計劃停機通知）。擴展計劃停機通知應列出擴展計劃停機的日期和時間。登記機構必須提前通知ICANN認可的登記商的天數如下：
(i) 擴展計劃停機時間範圍 - SRS = 90天；
(ii) 擴展計劃停機時間範圍 - DNS名稱伺服器 = 不允許有擴展計劃停機；以及
(iii) 擴展計劃停機時間範圍 - Whois = 不允許有擴展計劃停機。
擴展計劃停機通知的指標為信用等級5。
6.5 處理時間。 處理時間是服務可用性的測量，等同於系統服務的往返時間（"處理時間 "）。登記運營商將記錄所有協議交易的處理時間（即檢查、添加/創建、修改/更新和刪除）。處理時間將在每月時間範圍內進行測量，並根據附錄4按月向ICANN報告。如果所有ICANN認證的註冊商在每月時間範圍內新增的協議交易總量（逐個測量）超過登記運營商在前一月時間範圍內的實際協議交易量的20%以上，則ICANN認證的註冊商將無法獲得任何SLA信用，且如果登記運營商未能滿足本節6.5中規定的處理時間性能規範，則登記運營商對ICANN不承擔任何責任。
6.5.1 處理時間--檢查域名 = 25毫秒，95%。
(i) 檢查域名的處理時間適用於通過定義的協議（EPP）訪問的SRS，並測量特定域名的可用性檢查的處理時間。
(ii) 檢查域名的性能規範是在每月時間範圍內95%交易的往返時間為25毫秒。
檢查域名的處理時間指標為第三級信用。
75
6.5.2 處理時間--新增/創建 = 95%情況下為50毫秒。
(i) 新增/創建的處理時間適用於通過定義的協議（EPP）進行註冊機構-登記機構互動訪問的SRS，並衡量與域名相關的新增/創建交易的處理時間。
(ii) 新增/創建的性能規範是在一個月的時間範圍內處理的95%交易的往返處理時間為50毫秒。
新增/創建的處理時間指標是信用等級3。
6.5.3 處理時間--修改/更新和刪除域名 = 95%情況下為100毫秒。
(i) 修改/更新和刪除的處理時間適用於通過定義的協議（EPP）進行註冊機構-登記機構互動訪問的SRS，並衡量與域名相關的修改/更新和刪除交易的處理時間。
(ii) 修改/更新和刪除的性能規範是在一個月的時間範圍內處理的95%交易的往返處理時間為100毫秒。
修改/更新和刪除的處理時間指標是信用等級3。
6.5.4 處理時間--Whois 查詢 = 95% 情況下 5 毫秒。
(i) Whois 查詢的處理時間適用於 Whois，並測量 WhoIs 查詢的處理時間。
(ii) Whois 查詢的性能規範是在每月時間範圍內 95% 的交易中為 5 毫秒。也就是說，在每月時間範圍內 95% 的交易將從 Whois 接收到查詢的時間到它響應的時間需要 5 毫秒或更少。
Whois 查詢的處理時間指標為信用等級 3。
6.5.5 處理時間--DNS 名稱伺服器解析 = 95% 情況下 100 毫秒。
(i) DNS 名稱伺服器解析的處理時間適用於 DNS 名稱伺服器，並測量 DNS 查詢的處理時間。
(ii) DNS 名稱伺服器解析的性能規範是在每月時間範圍內 95% 的交易中為 100 毫秒。也就是說，在每月時間範圍內 95% 的交易將從名稱伺服器接收到 DNS 查詢的時間到它提供響應的時間需要 100 毫秒或更少。
DNS 名稱伺服器的處理時間指標為信用等級 3。
6.6 更新頻率。 登記運營商及時更新DNS名稱伺服器和Whois上的數據。ICANN認證的登記商通過SRS記錄這些更新。SRS然後更新DNS名稱伺服器和Whois。登記運營商幾乎實時地處理這些更新。
關於DNS名稱伺服器和Whois的更新頻率的承諾性能規範是在每月時間框架內95%的交易將在3分鐘內完成。也就是說，每月時間框架內95%的DNS名稱伺服器和Whois的更新將在3分鐘內完成。更新頻率是從登記運營商確認更新的時間到更新出現在DNS名稱伺服器和Whois的時間測量的。
76
更新頻率的性能將每月向ICANN報告，根據附錄4的要求。
6.6.1 更新頻率--DNS名稱伺服器 = 每月時間框架內95%為3分鐘。
更新頻率--DNS名稱伺服器是在每月時間框架內95%為3分鐘。
DNS名稱伺服器的更新頻率指標是信用級別4。
6.6.2 更新頻率--Whois - 每月時間框架內95%為3分鐘。
更新頻率——Whois在每月時間框架內為95%時為3分鐘。
Whois的更新頻率指標為信用等級4。
6.7 跨網絡名稱伺服器性能要求。 DNS名稱伺服器的往返時間和從互聯網的封包損失是登記運營商所提供質量服務的重要元素。然而，這些特性受到互聯網性能的影響，因此，登記運營商無法嚴格控制。因此，這些要求不屬於附錄10所載的服務水平協議下的SLA信用事項，也不構成登記運營商違反登記協議可主張的義務。
跨網絡名稱伺服器性能的承諾性能規範為測量的往返時間少於300毫秒，且平均封包損失少於1%，在整個每月時間框架內，任何五（5）分鐘的期間內封包損失不超過5%。跨網絡名稱伺服器性能測量可由ICANN在其選擇的時間進行，具體方式如下：
6.7.1 測量可通過從不同測量位置向每個.com DNS名稱伺服器發送DNS請求包的字符串，並觀察.com DNS名稱伺服器的響應來進行。（這些請求和回應的字符串被稱為"CNNP測試"。）測量位置將在互聯網中分佈。
6.7.2 每組請求數據包將由請求任意選擇的.com二級域名的UDP或TCP數據包組成，這些域名是預先選定的，以確保名稱在註冊局頂級域名中存在並且可以解析。可以記錄數據包丟失（即，未收到的響應數據包的百分比）及收到的響應數據包的平均往返時間。
6.7.3 為了滿足特定CNNP測試的數據包丟失和往返要求，必須滿足以下三個條件：
6.7.3.1 從每個測量位置到至少一個.com名稱服務器的往返時間和數據包丟失不得超過所需值；
6.7.3.2 從至少一個測量位置到每個.com名稱服務器的數據包丟失不得超過所需值；以及
6.7.3.3 在已識別的核心互聯網服務故障期間獲得的任何失敗CNNP測試結果不得被考慮。
77
6.7.4 為了確保測試樣本的多樣性，ICANN將在不同的時間（即，白天不同比較時間，以及一周中的不同天）進行CNNP測試。只有當.com DNS名稱服務器在CNNP測試中連續三次失敗（見上文第6.7.3節）時，註冊運營商才可被視為持續未能滿足跨網絡名稱服務器性能要求。
6.7.5 如果CNNP測試持續失敗，ICANN將向註冊運營商發出有關失敗的書面通知（附上備份數據），而註冊運營商將有六十天的時間來解決該失敗。
6.7.6 在根據本條款開始測試之前的六十天，ICANN將為註冊運營商提供評估ICANN將使用的測試工具、測量位置和程序的機會。如果註冊運營商不批准這些工具和程序，ICANN將直接與註冊運營商合作進行必要的修改。
7. 當事方的責任。
7.1 除了DNS名稱伺服器性能測量的情況外，登記運營商將從內部系統進行監控，以驗證本文件中所述的可用性和性能測量是否被滿足。
7.2 登記運營商將每月通過電子郵件向登記機構社區和根據附錄4向ICANN提供系統性能和可用性報告。
7.3 登記運營商將按附錄5A的規定提供Whois服務。
7.4 登記運營商將採取商業上合理的努力，在不可抗力事件終止後24小時內恢復系統服務的關鍵系統，並在不可抗力事件終止後48小時內恢復完整的系統功能。因不可抗力而造成的停機不應被視為本附錄7或SLA中的服務不可用。
7.5 如果登記運營商因遵守自生效日期起任何共識政策而未能滿足性能規範，並且在登記運營商因遵守該共識政策而無法以商業上合理的努力避免未能滿足性能規範的情況下，則登記運營商對ICANN或ICANN認可的登記機構不承擔任何信用或罰款責任，或不被視為違反其在登記協議下的任何義務。
7.6 登記運營商應向ICANN提供並在其網站上發布其準確的聯繫詳細信息，包括有效的電子郵件地址或網絡表單以及郵寄地址，以及處理與TLD中的惡意行為（包括DNS濫用）有關報告的主要聯繫人，這些定義在附錄11的(c)節（公共利益承諾）中，並應及時通知ICANN任何更改這些聯繫詳細信息的情況。在收到這些報告後，登記運營商應向舉報者確認已收到報告。
8. 附加服務
8.1 部分投資組合收購後的批量轉移 (BTAPPA)
部分投資組合收購後的批量轉移 (BTAPPA) 是一項註冊服務，適用於在一名ICANN認可的註冊商購買、
78
透過股權或資產購買、合併或類似交易的情況下，部分但不是全部的另一個ICANN認可的註冊商在.com頂級域名中的域名投資組合。
在完成批量轉移的至少十五天前，失去的註冊商必須向所有涉及批量轉移的域名註冊人提供書面通知，告知贊助商的批量變更。通知必須包括一個解釋，說明在批量轉移發生後，Whois記錄將如何變更，以及獲益註冊商的客戶支持和技術聯絡信息。
如果在任何適用的寬限期內根據BTAPPA服務轉移域名，則不會有任何信用。如上文第3節所述。轉移的註冊過期日期不受影響。
在轉移請求時處於以下狀態的域名將不會在BTAPPA中轉移："待轉移"、"贖回寬限期 (RGP)" 或 "待刪除"。處於自動續訂寬限期的域名可以進行批量轉移，但Verisign可能會拒絕對在批量轉移後但在自動續訂寬限期到期之前刪除的這些域名提供信用。
如果有合理證據顯示根據BTAPPA要求轉移是為了避免向Verisign或ICANN支付應付費用，或者如果有共同所有權或管理的註冊商在前六個月內已經請求BTAPPA服務，Verisign有權拒絕BTAPPA請求。
8.2 註冊一個單字符標籤的.com域名. 登記機構可以根據附錄7的附表1中所附的o.com服務描述和以下具體條件（以下稱為“o.com服務”）分配單字符標籤o.com：
(i)登記機構不得直接或間接地從o.com的銷售、分配、轉讓或續期中獲得任何收益，並僅根據協議第7.3(d)條中所規定的最高價格收取o.com註冊的標準登記費用。
(ii)儘管有附錄7，協議第3.1.1節（增加寬限期）規定，o.com不應有增加寬限期。
(iii)儘管有附錄7，協議第3.1.2節（續期/延長寬限期）規定，o.com在獲勝登記人續期o.com的第25年及之前不會有續期寬限期（如適用）。自第26年開始，獲勝登記人續期o.com及以後（如適用）將適用於o.com的續期寬限期。
(iv)儘管有附錄7，協議第3.1.3節（自動續期寬限期）規定，o.com將在自動續期寬限期內自動續期，每次續期為一年。
79
(v)儘管有附錄7，協議第3.3.2節（待刪除期間）規定，如果刪除，o.com將不包括在.com登記處的待刪除報告中，並將由登記機構持有，直到登記機構通過以後的拍賣或其他分配流程使o.com可用。
9. 實施新協議
登記運營商與ICANN同意定期（在生效日期後至少每十八個月一次）以誠意進行談判，討論可能實施與附件1（數據保管規範）、5A（註冊數據公開服務規範）、50億（註冊數據訪問協議服務規範）及7（功能與性能規範）相關的新RFC。
80
附件7的附表1
o.com服務描述
o.com服務
登記運營商將以其登記其他域名的方式登記o.com（SCDN）並遵從以下所列的例外情況。此外，SCDN將通過由登記運營商選擇的第三方拍賣服務提供商管理的拍賣來分配。SCDN的登記將通過一個具有競爭性和公平的拍賣過程進行，任何潛在的登記者均可參加拍賣過程，並在競標成功後選擇任何ICANN認可的註冊商來管理SCDN。對於登記者選擇.com的ICANN認可註冊商不會有任何限制。在拍賣前，登記運營商將提前至少60天通知註冊商，以便通知潛在的登記者。
非營利受益人
根據其作為服務提供者的唯一角色及其對SCDN沒有任何所有權的情況，登記運營商將不會獲得、接收或觸及任何SCDN拍賣收益的部分。相反，登記運營商僅會接收標準的登記費，該費用應符合協議第7.3(d)條規定的登記費用定價條款，這是在登記任何其他.com域名時的費用。
來自SCDN拍賣的收益將提供給一個或多個非營利組織，或者其繼任者，如本協議附件A中所述，並根據協議第3.1(d)(iv)(B)條的規定由ICANN和登記運營商同意為“保密”。非營利名單）。拍賣收益不會直接或間接用於惠及登記運營商、其關聯公司或其董事、高級職員或員工，除了這些收益被非營利組織用於惠及整體互聯網社區的微不足道的情況。非營利組織及其繼任者的使命將使拍賣SCDN所得資金的使用朝著互聯網社區的公共利益領域發展，這可能包括以下一項或多項：
o開放互聯網協議的開發、演變和使用
o加強公私部門實體的網絡安全準備和應對
o兒童的網上安全
o改善互聯網的安全性、穩定性和普遍可及性
o為了互聯網社群的利益而進行能力建設（例如協助發展中國家的人士申請成為登記機構和登記商）。
根據非營利機構名單，沒有任何非營利組織，包括其各自的繼任者，已經或將會進行任何貢獻，或代表登記運營商進行任何活動。
將收益分配給非營利受益者
81
獲勝的登記者將把拍賣收益提交給由第三方拍賣服務提供商設立的獨立免稅信託（"信託"）。一名獨立的第三方受託人（"第三方受託人"）將（i）選擇上述接收拍賣收益的非營利組織，並（ii）管理向非營利組織的拍賣收益的接受和分配。登記運營商及其附屬機構、董事、幹部或員工，將不會（i）擔任信託的受託人，（ii）被命名為信託中的成員，或（iii）被列為信託的當事方。第三方受託人除了本條款所規定的，將不會代登記運營商進行任何活動。
提供
根據o.com服務，登記操作方打算透過拍賣來分配SCDN。支付中標金額的收據將使登記人有權獲得初始五（5）年註冊。拍賣將由登記操作方選定的第三方拍賣服務提供商管理。SCDN將通過由第三方拍賣服務提供商負責的拍賣進行分配，如下所述。
第三方拍賣服務提供商將需要對潛在登記人進行預審，以參加拍賣，可能包括要求潛在登記人向第三方拍賣服務提供商提交文件，描述計劃的市場行銷及註冊域名的使用情況，展示支付能力，以及第三方拍賣服務提供商可能需要的其他要求。由第三方拍賣服務提供商組成的團隊將基於預先確定的資格審查並批准提案。
中標的登記人必須：(i) 在確定為贏家之日起的十四（14）個日曆日內，將中標金額的全額直接提交給信託（"中標的首期款"）；及(ii) 承諾在SCDN在初始五（5）年註冊期屆滿後每年向信託提交中標首期款的百分之五（5%）（每個"隨後的分期款"）直到，包括贏得者延長SCDN的第二十五（25）年（"後續分期付款的到期後續分期付款旨在鼓勵對非營利組織持續的資金流，直到後續分期的到期。例如，如果拍賣在2020年進行，且中標價為10,000美元，則SCDN的中標第一期付款將為10,000美元，並於2020年支付，並且在五（5）年初始期限之後每年的後續分期付款將為500美元，並於2026年至2045年支付（即，為第一期中標款項的5%）.
如果中標的登記者未能在十四（14）天的時間內完成付款交易，則：(i) 登記者將失去註冊SCDN的權利，並且 (ii) SCDN可能會提供給第二高競標者。這一過程將持續到收到全額付款為止.
在完成中標付款的第一期後，第三方拍賣服務提供商將向中標登記者發出授權碼。中標登記者
82
將把此授權碼提供給其選擇的登記機構。此中標登記者的登記機構必須將授權碼提供給登記運營商，以完成初始註冊。初始期限將自創建之日起五（5）年到期。登記運營商將向登記機構收取當時適用的每年間新域名註冊的登記費（乘以五（5）次增量，為期五年）對於SCDN，可使用與當前Verisign系統相關的帳戶或其支付安全（如.com登記-登記協議中定義）支付.
由於登記運營商未處理任何拍賣收益的付款，故中標登記者的登記機構不得使用與當前Verisign系統或其支付安全相關的帳戶，來確保中標款項的支付，無論是全部還是部分.-中標登記者的登記機構不得使用與當前Verisign系統或其支付安全相關的帳戶，以全額或部分方式確保中標款項的支付.
在註冊後，記錄登記處將能夠以當前執行所有更新的相同方式，對註冊者要求的SCDN進行任何更新。
如果登記機構認為獲勝的註冊者未遵守參與拍賣的拍賣協議的條款（"拍賣協議"），包括未能在到期時向非營利組織提供任何後續分期付款，登記機構將有權終止註冊，並且SCDN將進入標準的贖回寬限期。登記處僅在贖回寬限期內成功解決問題的情況下，才能恢復SCDN。在5天的待刪除期間結束後，SCDN將由登記機構保留，以便將來進行再拍賣或其他分配過程。
在初始註冊後，協議的附錄7中的規範將適用於所有EPP操作，除非本文件或附錄7第8.2節另有規定。
獲勝的註冊者可以根據協議的允許，將SCDN續註若干年，只要獲勝的註冊者在後續分期到期之前向信託提交獲勝出價的後續分期付款及標準註冊費用。在後續分期到期之前，為了續註SCDN，獲勝的註冊者必須向信託提交獲勝出價的後續分期付款，並在登記機構收到來自第三方受託人確認付款的通知後，該SCDN的記錄登記處可向登記機構提交續註請求，並將被收取每年增長的新域名註冊的適用費用。在後續分期到期後，為了續註SCDN，該SCDN的記錄登記處將向登記機構提交續註請求，並將被收取每年增長的新域名註冊的適用費用。
在後續分期的到期之前，獲勝投標的後續分期付款及當時適用的註冊費也將適用於SCDN的轉讓，因為在轉讓過程中將根據標準域名生命週期增加一年至SCDN的期限，但須遵守十年的最長限制。
83
如果在到期日前SCDN未被明確續約，則將以與非單一字符域名相同的方式自動續約一年。在後續分期的到期之前，獲勝註冊者必須在自動續約的14天內完成獲勝投標的後續分期付款，而登記機構必須完成當時適用的註冊費付款，否則登記中心保留明確刪除註冊的權利，並通過後續拍賣或其他分配方式使SCDN可用。如果SCDN未續約，則獲勝註冊者將解除其未來支付獲勝投標後續分期付款的承諾。
如果登記機構對SCDN進行了刪除，該SCDN將進入標準的30天贖回寬限期。如果在此期間未恢復SCDN，則該SCDN將進入5天的待刪除期限，並且該SCDN將無法重新註冊，可能會被重新拍賣或通過其他分配方式進行處置。
費用
獲勝投標的第一期款項將由獲勝註冊者支付給信託，並將由第三方受託人按如下方式分配：
o預先約定的金額將支付給(i)第三方拍賣服務提供商以進行拍賣管理服務，以及(ii)第三方受託人以提供與信託中資金的管理和分發有關的服務；
o一筆金額不超過1,000,000美元的資金將由信託保留作為第三方受託人為執行(a)拍賣協議及(b)所選非營利組織必須滿足的要求而可能產生的支出儲備，例如將資金用於互聯網社區的公共利益領域；
o中標的首期剩餘金額將分配給上述選定的非營利組織。
每期中標的後續付款將由中標登記者支付給信託，並由第三方受託人進行如下分配：
o預先約定的金額將支付給第三方受託人，用於管理和分配信託基金的服務；以及
o後續期數中標的剩餘金額將分配給上述所討論的非營利組織。第三方受託人將在收到付款後通知登記運營商。
84
附件7 - 保密的附表I的附錄A
附件7的附表1 (o.com服務描述)
安全性和穩定性研究
•互聯網安全中心 - https://www.cisecurity.org/
•DNS-OARC
•國家網絡取證與培訓聯盟 (NCFTA)
•國家網絡安全聯盟 (NCSA)
網際網路治理、發展與能力建設
•網際網路協會 (ISOC)
•IETF可持續發展基金會 - http://www.SustainIETF.org
線上安全
•Safekids.com - http://www.safekids.com/kids-rules-for-online-safety/
•Child Rescue Network - http://childrescuenetwork.org/
•iKeepSafe - http://ikeepsafe.org/
•ConnectSafely - http://www.connectsafely.org/
•危險中的孩子 - http://www.kidsindanger.org/
•安全代碼 - http://www.safecode.org/
•精明的網絡孩子 - http://www.savvycyberkids.org/
85
.com 登記協議附錄 8
.com 註冊機構-註冊商協議
本註冊機構-註冊商協議（以下稱為「協議」）由維瑞信公司（VeriSign, Inc.），一家特拉華州公司，商業地址位於維吉尼亞州雷斯頓Bluemont Way 12061號，及其全資子公司，包括維瑞信Sarl和維瑞信命名與目錄服務有限責任公司（「VNDS LLC」）（以下合稱為「維瑞信」）和 , a
，業務主要地點位於 （「註冊商」），通過其授權代表簽署，自最終當事方簽署之日起生效（以下稱為「生效日期」）。維瑞信和註冊商可單獨稱為「當事方」，合稱「當事方們」。
鑒於，許多註冊商在
.COm 頂級網域提供互聯網域名註冊服務，其中維瑞信運營並維護某些TLD服務器和區域文件；
鑒於，註冊商希望在.CO m TLD的多註冊商系統中註冊二級域名。
現在，因此，基於此處所包含的共同承諾、利益和約定以及其他善意和有價值的對價，收據、充足性和充分性在此得以確認，維瑞信與註冊商，意圖受法律約束，特此同意如下：
1.定義
1.1."機密信息"指所有信息和材料，包括但不限於計算機軟件、數據、信息、數據庫、協議、參考實現和文檔，以及功能和介面規格，由披露方提供給接收方並標註或以其他方式識別為機密，前提是如果通訊是口頭的，披露方將在披露後15天內以書面形式通知接收方。
1.2."DNS"指的是互聯網域名系統。
1.3."EPP"指可擴展的供應協議。
1.4."ICANN"指的是互聯網名稱與編號分配公司。
1.5."IP"指互聯網協議。
1.6."授權產品"指訪問支持的協議所需的知識產權，以及API和軟件的集合。
86
1.7."個人數據"指對任何已識別或可識別的自然人的數據。
1.8."Registered Name" refers to a domain name within the domain of the Registry TLD, whether consisting of two or more (e.g., john.smith.name) levels, about which Verisign or an affiliate engaged in providing registry services maintains data in a registry database, arranges for such maintenance, or derives revenue from such maintenance. A name in a registry database may be a Registered Name even though it does not appear in a TLD zone file (e.g., a registered but inactive name).
1.9.“Registered Name Holder(s)” means the holder(s) of a Registered Name.
1.10.“Registrar Accreditation Agreement” means that certain Registrar Accreditation Agreement between Registrar and ICANN pursuant to which ICANN has accredited Registrar to act as a registrar for one or more TLDs.
1.11."Registry TLD" means the .COm TLD.
1.12."Supported Protocol" means Verisign's implementation of EPP, or any successor protocols, supported by the System.
1.13.The "System" refers to the shared registration system operated by Verisign for registration of Registered Names in the Registry TLD.
1.14.A "TLD" is a top-level domain of the DNS.
2.OBLIGATIONS OF THE PARTIES
2.1.系統運作及訪問。 在本協議的有效期內，Verisign應運作系統並提供登記機構訪問系統，以傳輸域名註冊資訊至系統。此協議中的任何內容均不賦予登記機構強制執行Verisign與ICANN之間任何協議的權利。
2.2.登記維護由登記機構贊助。 在本協議、ICANN要求及Verisign要求的條款下，包括但不限於ICANN授權的要求，Verisign應在登記機構已支付第5.1小節所需費用的有效期間內，維護由登記機構贊助的註冊名稱的登記在系統中。
2.3.EPP、API及軟件的分發。 在本協議的生效日期後不遲於三（3）個工作日內，Verisign應向登記機構提供 (i) 支援協議的完整文件，(ii) 用於支援協議的"C"和/或"Java"應用程式介面（"API"）及其文件， (iii) 參考客戶端軟件（"軟件"），以便登記機構能通過系統為註冊頂級域名開發其系統。如果Verisign選擇修改或升級API和/或支援協議，Verisign應在此類更新可用時，迅速向登記機構提供更新的
87
API及文件及更新的軟件。
2.4.登記商對客戶支持的責任。 登記商應提供
(i) 接受註冊、取消、修改、續訂、刪除或轉移註冊名稱的訂單的支持，及 (ii) 向註冊名稱持有者提供客戶服務（包括域名記錄支持）、計費和技術支持。登記商應根據ICANN政策，向註冊名稱持有者提供針對關鍵情況（如域名劫持）的緊急聯絡或24/7支持信息。
2.5.數據提交要求。 作為登記商在登記管理局TLD中註冊和贊助註冊名稱的一部分，登記商應根據要求或允許提交完整數據：(a) 根據Verisign與ICANN的登記協議，該協議不時可能會修訂；和/或 (b) 根據Verisign不時向登記商提供的系統技術規範（統稱為“所需數據元素”）。登記商應及時向Verisign提交註冊名稱持有者有關註冊名稱的註冊信息的任何更正或更新。
2.6.許可。 登記商授予Verisign一個非獨佔、無版稅、不可轉讓的（除非根據Verisign與ICANN的登記協議轉讓給ICANN或其指定人）全球有限許可，適用於所需數據元素：(a) 根據不時向登記商提供的系統技術規範的要求或允許使用；和/或 (b) 根據Verisign與ICANN的登記協議的要求或允許使用和展示，該協議不時可能會修訂。
2.7.登記商的註冊協議和域名爭議政策。
(a)登記機構必須與每位註冊名稱持有人有效且可執行的電子或紙質註冊協議有效，該協議可由登記機構不時修訂，並提供一份副本給Verisign。登記機構應在Verisign要求時提供登記機構的註冊協議副本。登記機構的註冊協議應包含本協議所要求的條款及與登記機構根據本協議對Verisign的義務一致的其他條款。登記機構在其域名註冊業務中應遵守統一域名爭議解決政策和內部登記機構轉移政策，這些政策分別由ICANN董事會於1999年8月26日和2008年11月7日採納，並可不時修訂。
(b)登記機構與每位註冊名稱持有人的註冊協議還應包括以下內容：
(i)禁止註冊名稱持有人分發惡意軟件、濫用操作機器人網絡、釣魚、藥品詐騙、盜版、商標或版權侵權、欺詐或欺騙性行為、假冒或
88
以其他方式從事違反適用法律的活動，並根據適用法律及任何相關程序對此類活動提供後果，包括暫停註冊名稱的註冊；
(ii)一項條款要求註冊名稱持有人確認並同意，Verisign保留權利拒絕、取消、重定向或轉移任何註冊或交易，或將任何域名放置於註冊鎖、保留或類似狀態，根據其認為必要的無限且唯一的裁量權：(1) 遵守任何被普遍認可為網際網路權威的行業組織採納的規範（例如，RFC），(2) 更正Verisign或任何登記機構在域名註冊過程中所犯的錯誤，(3) 因未支付Verisign的費用，(4) 針對對登記總域名、系統、Verisign的名稱伺服器運作或互聯網的即時及重大威脅，(5) 確保遵守適用法律、政府規則或法規，或依據任何政府、行政或法律機構的法律命令或傳票，或具有管轄權的法院，(6) 停止或防止對本協議、操作要求或根據Verisign與ICANN的登記協議的任何條款和條件的違反；
(iii)要求註冊名稱持有人對Verisign及其分包商，以及其及其董事、官員、員工、代理和關聯公司進行賠償、辯護並使其免受任何及所有索賠、損害、責任、費用和開支的條款，包括因註冊名稱持有人的域名註冊而產生或與之相關的合理法律費用和開支，無論因何原因。註冊協議還應要求，此賠償義務在註冊協議終止或到期後仍然有效。
2.8.安全連接。
(a)註冊商同意在其域名註冊業務中開發並使用所有必要的技術和限制，以確保其與系統的連接是安全的。在註冊商系統與系統之間交換的所有數據應受到保護，以避免意外披露信息。註冊商應採取商業上合理的措施，以防止其在此授予的訪問系統權限被用於(i) 除其現有客戶外，向其他實體發送未經請求的大量商業廣告或推銷；或(ii) 啟用高容量、自動化的電子處理，向Verisign、任何其他根據與ICANN的協議運營的註冊機構，或任何ICANN認可的註冊商的系統發送查詢或數據，除非合理必要以註冊域名或根據任何操作要求修改現有註冊。
89
(b)每個EPP會話應使用雙向安全套接層（"SSL"）協議進行身份驗證和加密。註冊商同意使用由註冊處識別的商業認證機構發出的X.509服務器證書和其註冊商密碼來驗證與系統的每個EPP客戶端連接，該密碼僅向有需要知道的員工披露。註冊商同意在得知其註冊商密碼以任何方式被洩露或其服務器證書被發證認證機構撤銷或以任何方式洩露後四（4）小時內通知註冊處。
(c)在事先書面通知註冊管理機構的情況下，Verisign可以要求其他行業標準的安全條件、實踐或技術，以確保系統的安全和穩定，這些條件、實踐或技術將由Verisign隨時自行全權決定。
2.8.1.個人資料的處理。
Verisign應通知註冊管理機構有關註冊管理機構提交給Verisign的個人資料的收集目的、此類個人資料的預期接收者（或接收者的類別）以及訪問和修正此類個人資料的機制。Verisign應採取合理措施來保護個人資料，以防止其遺失、濫用、未經授權的披露、變更或破壞。Verisign不得以與提供給註冊管理機構的通知不符的方式使用或授權使用個人資料。Verisign可能不時使用所收集的人口統計數據進行統計分析，但該分析不會披露個別的個人資料，並且該使用符合提供給註冊管理機構的關於目的和程序的通知。
2.8.2.授權碼註冊機構不得為不同註冊名稱持有者在同一註冊機構註冊的域名提供相同的註冊機構生成的授權<authinfo>碼。Verisign可以自行決定選擇修改給定域名的<authinfo>碼，並通過符合EPP的機制（即EPP<poll>或EPP<domain:Info>）通知贊助註冊機構這些修改。這些機制的文檔將由Verisign提供給註冊機構。註冊機構應向註冊名稱持有者及時提供授權碼及其修改授權碼的能力。註冊機構應在五（5）個日曆天內對註冊名稱持有者有關訪問和/或修改授權碼的任何查詢做出回應。
2.9.域名查詢能力。 註冊機構同意在其域名註冊業務中使用Verisign的註冊域名查詢能力，以確定所請求的域名是否可用或目前無法註冊。註冊機構還同意自費提供一個註冊數據目錄服務，提供免費 提供基於公共查詢的訪問，以獲取有關由註冊商為登記頂級域名註冊的所有活動註冊名稱的最新（即至少每日更新）數據。可訪問的數據應由不時根據ICANN採納的規範或政策或註冊商與ICANN之間的註冊商認證協議所指定的元素組成。
90
根據ICANN採納的規範或政策或註冊商與ICANN之間的註冊商認證協議，不時進行的轉讓。
2.10.註冊的贊助轉讓。 註冊商同意根據可能不時由ICANN修訂的跨註冊商轉讓政策（"轉讓政策"），實施從另一個註冊商轉讓註冊名稱註冊到註冊商，反之亦然，或從一個註冊名稱持有人轉讓到另一個註冊名稱持有人的轉讓。
2.11.時間。 註冊商同意，在任何有關域名註冊錄入登記數據庫的時間爭議中，Verisign記錄中所示的時間應優先。
2.12.遵守操作要求。 註冊商應遵守以下每一項要求，並進一步在其與每個註冊名稱持有人的註冊協議中，包括該註冊名稱持有人遵守以下每一項要求的義務，視情況而定：
(a)ICANN標準、政策、程序和做法，Verisign根據登記協議或與ICANN的其他安排承擔監管責任；以及
(b)由Verisign不時以非任意方式建立的登記TLD的運營標準、政策、程序和做法（"運營要求"），適用於所有註冊商，包括Verisign的關聯公司，並與Verisign與ICANN的登記協議相一致，根據Verisign通知註冊商的條款和條件。
2.13.技術問題或違反協議的解決方案。 註冊商同意聘用具備足夠技術培訓和經驗的必要員工、承包商或代理，以回應和修復所有有關使用支持的協議、API和Verisign系統與註冊商系統之間的技術問題。註冊商同意，在系統重大降級或其他緊急情況下，或在註冊商違反運營要求或違反本協議的情況下，Verisign可以自行酌情暫時暫停或限制對系統的訪問。此類暫時暫停或限制應以非任意的方式適用，並公平地適用於任何具有類似情況的註冊商。
2.14.禁止的域名註冊。 除了遵守ICANN標準、政策、程序和做法限制可註冊的域名外，註冊商同意遵守適用的法律和法規限制可註冊的域名。註冊商進一步承認並同意，Verisign保留拒絕、取消、重定向或轉移任何註冊或交易的權利，或根據其認為必要的決定，將任何域名放置在登記鎖定、保留或類似狀態下。 根據本協議第2.7(b)(ii)節中所述的目的，以其無限的單獨裁量決定。
91
2.15.ICANN要求。 Verisign在本協議下的義務隨時可能根據ICANN要求的規定進行修改，包括共識政策。儘管本協議中有任何相反的內容，註冊機構應根據ICANN定義的時間表遵守任何此類ICANN要求。
2.16.認可的註冊機構。 在本協議有效期內，註冊機構應維持註冊機構認證協議的全面有效性及其在ICANN中的註冊機構認證，作為註冊TLD的註冊機構。
3.許可證
3.1.許可授予。 根據本協議的條款和條件，Verisign此刻授予註冊機構，並註冊機構接受一項非獨佔、免版稅、不可轉讓的全球有限許可，用於本協議的期限和目的，使用授權產品及其更新和重新設計，以在登記TLD中僅提供域名註冊服務，並不為其他目的。授權產品及其更新和重新設計將使註冊機構能夠代表其註冊名稱持有者在登記機構註冊域名。註冊機構使用授權產品及其更新和重新設計後，將能夠在系統上執行以下操作：(i) 檢查域名的可用性，(ii) 註冊域名，(iii) 重新註冊域名，(iv) 取消其所註冊的域名的註冊，(v) 更新域名的名稱伺服器，(vi) 在適當授權下將域名從其他註冊機構轉移至自己。 (vii) 查詢域名註冊記錄，(viii) 註冊名稱伺服器，(ix) 更新名稱伺服器的IP地址，(x) 刪除名稱伺服器，(xi) 查詢名稱伺服器，(xii) 建立和結束經過認證的會話。
3.2.使用限制。 儘管本協議中有任何其他條款，但未經Verisign的書面同意，登記機構不得：(i) 轉授已授權產品或以其他方式允許任何非登記機構的方使用該已授權產品，(ii) 發布、分發或允許公開該已授權產品，僅限於登記機構的員工、承包商和代理人，用於登記機構的域名註冊業務，(iii) 反編譯、逆向工程、複製或重新設計該已授權產品以任何未經授權的目的，(iv) 以任何聯邦、州或地方規則、法規或法律的違規方式使用或允許使用該已授權產品，或出於任何非法目的。登記機構同意採取必要措施，以防止其本協議所授予的對系統的訪問被用於(i) 允許、啟用或以其他方式支持通過電子郵件、電話或傳真向非登記機構客戶的實體發送大量未經請求的商業廣告或招攬；或(ii) 啟用高容量、自動化、電子流程，向Verisign的系統、與ICANN簽署協議的其他登記機構或任何ICANN認可的登記機構發送查詢或數據，除非在合理必要的情況下註冊域名或根據任何運作要求修改現有註冊。
92
3.3.對已授權材料的變更。 Verisign可能不時更換或修改此處授權的已授權產品。Verisign將在實施對所支持協議、API或此處授權的軟件的任何重大變化之前，至少提前九十（90）天通知登記機構。
4.支援服務
4.1.工程支援。 Verisign同意在合理的工程電話支援時間內（在美東時間上午9時至下午5時之間或雙方協商一致的其他時間），為登記機構提供合理的工程電話支援，以解決與登記機構使用系統相關的工程問題。
4.2.客戶服務支持。 在本協議期間，Verisign將為註冊機構提供合理的電話、網絡和電子郵件客戶服務支持，但不針對註冊名稱持有者或註冊機構的潛在客戶，僅針對與系統及其運作相關的非技術性問題。Verisign將在支持協議、API和軟件的實施過程中，為註冊機構提供一個電話號碼和電子郵件地址以便進行此類支持。第一級電話支持將在每週7天、每日24小時提供。
5.費用
5.1.註冊費用。
(a)註冊機構同意向Verisign支付展覽A中列明的不可退還費用，或根據下文第5.1(b)條中所列的通知條款確定的其他金額，以支付初始和續期註冊及Verisign提供的其他附帶和輔助服務（統稱為“註冊費用”）。
(b)Verisign保留調整註冊費用的權利，前提是任何價格上調應提前六（6）個月通知註冊機構（通過電子郵件、親自交付、掛號郵件或快遞服務），並且該等調整須符合Verisign與ICANN的註冊協議。
(c)註冊機構應向Verisign提供由不可撤回的信用證或現金存款組成的付款擔保（以下稱為“付款擔保”）。付款擔保的金額確定註冊機構在Verisign系統中的信用限額，應基於預期的每月註冊量和其他可收費交易。註冊機構同意根據Verisign的信貸和計費政策，修改其付款擔保以支持可計費交易量的增長。Verisign將每月發票給註冊機構，針對每個月的註冊費用進行事後結算。所有註冊費用在收到Verisign的每月發票後應立即支付。為了滿足任何未清賬戶餘額，Verisign可以
93
動用註冊機構的付款擔保。如果發生此情況，註冊機構同意在提款完成後立即補充付款擔保至提款前的水準。如果註冊機構的付款擔保耗盡，則將暫停註冊機構的域名註冊，且在補充付款擔保之前不接受新的註冊。
(d)根據本協議所需的登記費用不包括稅金。所有由任何政府或其任何政治分支機構對任何服務、軟件和/或硬件的費用所徵收的各種稅項、關稅、費用及其他政府收費（包括商業稅、徵費、銷售稅、營業稅、服務稅、使用稅和增值稅，但不包括基於Verisign淨收入的稅項）均由登記機構承擔，並不視為該登記費用的一部分、扣除項或抵銷項。所有應付給Verisign的款項必須在不因任何稅項、費用或罰款而進行扣除或扣繳的情況下支付，法律要求的情況下，登記機構需支付的款項須在必要的程度上增加，以確保在進行該等扣除或扣繳後，Verisign可收取並保留（無需承擔相關責任）等同於其未因該扣除或扣繳而應收的淨款項。
5.2.變更註冊商贊助的域名。 註冊商可以按照轉讓政策從另一個註冊商那裡接管已註冊名稱持有者的現有域名註冊。
(a)根據轉讓政策進行的每次域名註冊的贊助轉讓，註冊商同意向Verisign支付與一年延續相關的續訂登記費，如上述所述。失去的註冊商的登記費用不會因任何此類轉讓而退還。
(b)對於在轉讓政策的b部分下經ICANN批准的轉讓，註冊商同意向Verisign支付美金0（對於50,000個名稱或更少的轉讓）或美金
50,000（對於超過50,000個名稱的轉讓）。
本第5.2條款下的費用應在收到Verisign根據支付安全發出的發票後立即支付。
5.3.ICANN費用的收費。 Registrar agrees to pay to Verisign, within five (5) days of the date when due, any variable registry-level fees paid by Verisign to ICANN, which fees shall be secured by the Payment Security. The fee will consist of two components; each component will be calculated by ICANN for each registrar:
(a)The transactional component of the Variable Registry-Level Fee shall be specified by ICANN in accordance with the budget adopted by the ICANN
94
Board of Directors for each fiscal year but shall not exceed the amount set forth in the Registry Agreement.
(b)The per-registrar component of the Variable Registry-Level Fee shall be specified by ICANN in accordance with the budget adopted by the ICANN Board of Directors for each fiscal year, but the sum of the per registrar fees calculated for all registrars shall not exceed the total Per-Registrar Variable funding established pursuant to the approved ICANN Budget.
5.4.Non-Payment of Fees. Timely payment of fees owing under this Section 5 is a material condition of performance under this Agreement. In the event that Registrar fails to pay its fees within five (5) days of the date when due, Verisign may: (i) stop accepting new initial or renewal registrations from Registrar; (ii) delete the domain names associated with invoices not paid in full from the Registry database; (iii) give written notice of termination of this Agreement pursuant to Section 6.1(b) below; and (iv) pursue any other remedy under this Agreement.
6.雜項
6.1.Term of Agreement and Termination.
(a)協議的條款；修訂。 本協議的雙方的責任和義務自生效日開始適用，持續至生效日起的六十（60）個月的日曆月的最後一天（以下稱為"初始期限"）。在初始期限結束後，本協議的所有條款將自動續約五（5）年，直到本協議根據此處的規定被終止，登記機構選擇不續約，或Verisign停止運營該註冊管理局的註冊頂級域名。在Verisign的註冊管理局-登記機構協議的修訂獲得ICANN批准或採納的情況下，登記機構在收到任何該類修訂的通知後有三十（30）天的時間來審查、評論並執行取代本協議的修訂協議，或者登記機構可以在該三十（30）天期限內行使其選擇，立即以書面通知Verisign終止本協議；但若Verisign在通知日期的三十（30）天期限內未收到登記機構簽署的該修訂或終止通知，則登記機構將被視為在通知日期後第31天已簽署該修訂。
(b)因故終止。 若任一方實質性違反本協議的任何條款，包括其在本協議下的任何陳述和保證，且該違反在另一方書面通知後的三十（30）個日曆日內未得到實質性補救，則未違約方可以通過書面通知另一方終止本協議，終止日期以該終止通知中的日期為準。
95
未違約方可以以書面通知的方式終止本協議，終止日期以該通知中的指定日期為準。
(c)登記機構的選擇終止。 登記機構可以在任何時候通過給Verisign發出三十（30）天的終止通知來終止本協議。
(d)因登記機構的認證喪失而終止。 若登記管理者的域名登記局TLD之認證被ICANN或其繼任者終止或到期且未續約，本協議將立即終止。
(e)在指定繼任登記運營商的情況下終止。 若美國商務部或ICANN適當地指派另一實體來運營域名登記局，本協議將終止。
(f)在破產情況下終止。 如果一方被裁定為破產或無法償還債務，或如果由一方發起或對一方提出的程序尋求與任何關於破產的法律相關的救濟、重組或安排，或尋求為債權人利益的任何轉讓，或尋求任命接收人、清算人或受託人來管理一方的財產或資產，或尋求對一方的業務進行清算、解散或終止，任何一方均可終止本協議。
(g)終止的影響。 在本協議到期或終止時，Verisign將在其有權這樣做的範圍內，完成在到期或終止日期之前由登記管理者處理的所有域名的註冊，前提是登記管理者對Verisign的註冊費支付為當前和及時的。在本協議的任何到期或終止後，登記管理者應(i)將其對已註冊名稱的註冊的贊助轉移到另一個獲得許可的登記管理者，並遵守轉移政策的第b部分，或任何經商務部或ICANN（如適用）建立或批准的其他程序；且(ii)要麼返回Verisign，要麼向Verisign證明其已銷毀在本協議下收到的所有保密信息。如果終止，Verisign保留立即聯絡所有已註冊名稱持有者的權利，以促進已註冊名稱持有者的有序和平穩過渡到其他ICANN認證的登記管理者。所有欠Verisign的費用應立即到期並應支付。
(h)生存。 在本協議終止的情況下，以下條款將繼續有效：(i) 第2.6條（許可），第2.7條（登記機構的登記協議和域名爭議政策），第2.8.1條（個人資料處理），第6.1(g)條（終止的效力），第6.1(h)條（持續效力），第6.2條（無第三方受益；各方的關係），第6.5條（書面修訂），第6.6條（律師費用），
96
第6.7條（爭議解決；法律選擇；管轄地），第6.8條（通知），第6.10條（機密信息的使用），第6.11條（延遲或省略；豁免），第6.12條（責任限制），第6.13條（解釋），第6.14條（智慧財產），第6.15(c)條（不保證的聲明），第6.16條（賠償），以及第6.17條（完整協議；可分割性）；(ii) 登記名稱持有人的賠償、辯護與保護Verisign的義務，如第2.7(b)(iii)條所述；及(iii) 登記機構根據本協議第5條所列的支付義務，涉及在此協議有效期間內產生的費用。
6.2.無第三方受益；各方的關係。 本協議不提供且不應被解釋為提供第三方（即非本協議的當事方），包括任何登記名稱持有人，任何救濟、索賠、訴因或特權。 本協議中的任何內容均不應被解釋為在各方之間創造雇主-雇員或代理關係、合夥關係或合資事業。
6.3.不可抗力。 任何一方均不應對因天災、罷工、停工、網路攻擊、保護登記TLD的安全和穩定、Verisign的名稱伺服器操作或互聯網的重大的即時威脅、政府行為或指令、戰爭、騷亂或民事騷動、設備或設施短缺（這些通常出現在電信服務提供商身上），或其他類似超出該方合理控制範圍的力量，而導致無法履行任何義務（除了支付義務）或無法提供服務而承擔責任。
6.4.進一步保證。 各方應執行並/或促使交付給其他各方所需的各種文書及文件，並應採取其他行動，以便滿足其他各方合理要求的目的，以執行或證明本協議所預想的任何交易。
6.5.書面修訂。 除非本協議另有規定，對本協議的任何修訂或補充應以書面形式進行，並由雙方正式簽署。由ICANN批准並由註冊商購買的任何新服務，應根據Verisign通過本協議附錄或註冊商與Verisign簽署的其他協議所訂立的條款和條件進行。
6.6.律師費用。 如果針對任一方就本協議的執行或任何條款的執行提起任何法律行動或其他法律程序（包括仲裁），獲勝方有權收回合理的律師費用、成本和支出（此外，還包括獲勝方可能獲得的其他救濟）。
6.7.爭議解決；法律選擇；管轄地。 各方應在訴訟之前先嘗試解決彼此之間的任何爭議。本協議應依據美國維吉尼亞州的內部法律進行解釋和適用，而不考慮任何法律選擇規則的影響。
97
會導致本協議各方的權利和義務適用於維吉尼亞聯邦以外的任何司法管轄區的法律。與本協議或本協議任何條款的執行有關的任何法律行動或其他法律程序應在位於維吉尼亞聯邦東區的任何州或聯邦法院提起或開始。每一方明確且不可撤銷地同意並服從位於維吉尼亞聯邦東區的每一州和聯邦法院（以及位於維吉尼亞聯邦的每一上訴法院）的管轄權和審判地，與任何此類法律程序相關。
6.8.注意事項。 根據本協議要求或允許交付給任何一方的任何通知或其他通信應以書面形式進行，並在通過手交、掛號郵件、快遞或特快服務、電子郵件或在工作時間內通過傳真交付到以下地址時，應被視為適當交付、發出和接收： 或傳真號碼，列於該方姓名下方，除非該方以書面形式通知變更地址：
如果是登記人:
客戶名稱：
注意事項：
實體地址：
城市，州 郵政編碼:
電話號碼:
傳真號碼:
電子郵件：
副本：
客戶姓名:
注意事項：
實際地址:
城市，州 郵政編碼：
電話號碼：
傳真號碼：
電子郵件：
如果寄給Verisign:
VeriSign, Inc.
12061 Bluemont Way
美國維吉尼亞州雷斯頓，郵政編號20190 收件人：總法律顧問
電話: +1 703 948 3200
98
傳真: +1 703 435 4921 電子郵件: legal@verisign.com
抄送给（不构成通知）：
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
收件人: 客戶事務辦公室 電話: +1 703 948 3200
傳真: +1 703 948 3977
電子郵件：cao@verisign-grs.com
6.9.轉讓/再授權。 除非本協議另有明確規定，本協議的條款應使本協議各方的繼任者和允許的受讓人受益並受其約束。登記機構不得在未經Verisign事先書面同意的情況下，轉讓、再授權 或轉讓本協議下的權利或義務予任何第三方。Verisign可以在未經登記機構同意的情況下，將其在本協議下的權利或義務轉讓給其關聯公司。
6.9.1.與ICANN協議轉讓相關的轉讓如果Verisign與ICANN的注冊商TLD協議被有效轉讓，則Verisign在本協議下的權利將自動轉讓給注冊協議的受讓人，前提是受讓人承擔Verisign在本協議下的義務。如果登記機構與ICANN的注冊商TLD註冊協議被有效轉讓，則登記機構在本協議下的權利將自動轉讓給登記機構的註冊認證協議的受讓人，前提是隨後的登記機構承擔登記機構在本協議下的義務。
6.10.使用保密信息。 在本協議的有效期內，每一方（"披露方"）可以向另一方（"接收方"）披露其保密信息。每一方對本協議下披露的保密信息的使用和披露均受以下條款和條件的約束：
(a)接收方應當嚴格保密，並採取一切合理措施維護披露方所有機密信息的機密性和安全性，包括實施合理的物理安全措施和操作程序。
(b)接收方同意，將披露方的任何機密信息僅用於行使其在本協議下的權利或履行其義務，絕不會用於其他任何目的。
99
(c)接收方不得以任何方式向他人披露披露方的任何機密信息；但如果接收方是公司、合夥企業或類似實體，則可向那些有實際需要知道該機密信息的接收方的高級職員、員工、承包商和代理人披露，前提是接收方應告知這些人員該機密信息的保密性並採取合理措施來維持其機密性。
(d)接收方不得修改或刪除出現在披露方任何機密信息上的保密標記和/或版權通知。
(e)接收方同意不根據機密信息準備任何衍生作品。
(f)儘管如此，本小節6.10對於以下信息不施加義務：(i) 在沒有保密協議的情況下披露，且該披露事先經披露方書面同意；或 (ii) 因接收方的錯誤而已進入公共領域的信息；或 (iii) 接收方在披露前已知的資訊；或 (iv) 接收方在未使用機密信息的情況下獨立開發的信息；或 (v) 雖然披露方向公眾普遍提供而無任何披露限制的信息；或 (vi) 法律、法規或法院命令要求披露的信息；前提是，如果接收方被法律、法規或法院命令要求披露披露方的任何機密信息，接收方將在進行任何此類披露之前，及時以書面方式通知披露方，以便於披露方向適當當局尋求保護令或其他適當的救濟，所有費用由披露方承擔。接收方同意配合披露方以尋求此類命令或其他救濟。接收方進一步同意，如果披露方未能阻止請求的法律機構要求披露機密信息，將僅提供法律要求的機密信息部分。
6.11.延遲或遺漏；放棄。 在本協議下，任一方未能行使任何權力、權利、特權或救濟，或任一方在行使本協議下的任何權力、權利、特權或救濟時的延遲，不應視為放棄此等權力、權利、特權或救濟；且對於任何此等權力、權利、特權或救濟的單次或部分行使或放棄，亦不應排除任何其他或進一步的行使，或任何其他權力、權利、特權或救濟之行使。除非該放棄的索賠、權力、權利、特權或救濟明確在書面文檔中詳述，否則任何一方不得被視為放棄因本協議而產生的任何索賠或本協議下的任何權力、權利、特權或救濟。
100
代表該方的書面文檔；而且此類放棄僅在作出時的特定情況下適用，並且不會具有任何效力。
6.12.責任限制。
(a)在任何情況下，VERISIGN不對REGISTRAR承擔任何特殊、間接、附帶、懲罰性、典範或後果性損害賠償責任，或因本協議產生或與之相關的任何因利潤損失而引起的損害賠償，即使VERISIGN已被告知此類損害的可能性。在任何情況下，各方的最高總責任不應超過（I）在本協議條款下，在前十二（12）個月期間支付給VERISIGN的總金額，或（ii）500,000美元。
(b)第6.12(a)節中規定的責任上限和損害賠償排除不適用於第6.10節（保密性）和第6.16節（賠償責任）。
6.13.施工。 各方同意，任何旨在針對起草方解釋模糊之處的解釋規則在本協議的解釋或詮釋中不得適用。
6.14.知識產權。 根據上述第2.6條的規定，各方將繼續獨立擁有其知識產權，包括所有專利、商標、商業名稱、服務標記、版權、商業秘密、專有流程以及所有其他形式的知識產權。
6.15.陳述與保證
(a)登記機構。 登記機構聲明並保證： (1) 它是一家根據法律正當成立、有效存在且良好運作的公司，
(2) 它擁有執行、交付和履行本協議下義務所需的一切公司權力和授權， (3) 它在本協議的有效期間內，將繼續獲得ICANN或其繼任者的認證，根據登記機構認證協議或經ICANN批准的繼任協議， (4) 本協議的簽署、履行和交付已獲得登記機構的妥善授權，(5) 登記機構進入並履行其在本協議下義務所需的任何政府或監管機構的進一步批准、授權或同意不再需要取得或作出。
(b)維瑞信。 維瑞信聲明並保證： (1) 它是一家根據特拉華州法律正當成立、有效存在且良好運作的公司， (2) 它擁有執行、
101
根據本協議履行其義務，(3) 此協議的執行、履行和交付已獲得Verisign的正式授權，以及(4) Verisign無需獲得或作出任何政府或監管機構的進一步批准、授權或同意，即可進入並履行其在本協議下的義務。
(c)免責聲明。 LICENSED PRODUCT、SUPPORTED PROTOCOL、EPP、APIs 和 SOFTWARE 皆以「原樣」及不提供任何形式的保證。VERISIGN明確否認所有明示或暗示的保證和/或條件，包括但不限於對於適銷性或滿意質量的隱含保證及對於特定用途的適合性和不侵犯第三方權利的保證。VERISIGN不保證LICENSED PRODUCT、SUPPORTED PROTOCOL、EPP、APIs 或 SOFTWARE中包含的功能能滿足登記機構的要求，或LICENSED PRODUCT、SUPPORTED PROTOCOL、EPP、APIs 或 SOFTWARE的操作將不會中斷或無錯誤，或LICENSED PRODUCT、SUPPORTED PROTOCOL、EPP、APIs 或 SOFTWARE中的缺陷將會被修正。此外，VERISIGN不保證也不做任何關於LICENSED PRODUCT、SUPPORTED PROTOCOL、EPP、APIs、SOFTWARE或相關文檔在其正確性、準確性、可靠性或其他方面的使用或結果的陳述。如LICENSED PRODUCT、SUPPORTED PROTOCOL、EPP、APIs 或 SOFTWARE被證明存在缺陷，登記機構將承擔對登記機構自身系統和軟體所有必要維護、修理或修正的全部費用。
6.16.保障條款。 登記機構將自負費用，並在Verisign根據本段落提出要求後的三十（30）天內，對Verisign及其僱員、董事、高級職員、代表、代理和關聯公司承擔賠償、辯護並保護其免受任何基於或源自任何索賠或聲稱的索賠、訴訟、行動或其他程序的影響：(i) 與登記機構的任何產品或服務相關；(ii) 與登記機構與任何註冊名稱持有人的協議，包括登記機構的爭議政策相關；或(iii) 與登記機構的域名註冊業務相關，包括但不限於登記機構的廣告、域名申請流程、系統和其他流程、收取的費用、計費實踐以及客戶服務；但在任何此情況下：(a) Verisign應及時通知登記機構有關任何此類索賠，並且(b) 在登記機構書面請求下，Verisign將向登記機構提供所有可用的信息。
102
及對於註冊機構為了捍衛該索賠而合理必要的協助，前提是註冊機構向Verisign償還其實際和合理的費用。Verisign有權控制Verisign對任何索賠或訴訟的辯護，通過其選擇的律師，律師的費用應根據本文所述的賠償條款進行賠償。註冊機構在未經Verisign事先書面同意的情況下，不得對任何可賠償的索賠進行和解或妥協，此同意不得無理扣留。註冊機構將支付與任何此類可賠償索賠、訴訟、行動或程序有關的所有費用、損害和支出，包括但不限於評判對Verisign不利或由Verisign實際產生的合理律師費用和成本。
6.17.完整協議；可分割性。 本協議，包括附件A和b，構成雙方就此事宜之間的完整協議，並取代任何先前的協議、陳述、聲明、談判、理解、提案或計畫，不論口頭或書面，與此處明確列出的主題有關。如果本協議的任何條款被視為非法、無效或不可執行，各方同意該條款應當在最大限度可許可的範圍內予以執行，以實現各方的意圖，並且本協議其餘條款的有效性、合法性和可執行性不會因此受到影響或損害。如有必要以實現各方的意圖，各方應本著誠信進行協商以修訂本協議，用可執行的語言替換不可執行的語言，並使其意圖盡可能接近。
6.18.服務水平協議。 本協議的附錄10，如有不時修改，應納入本協議並作為附件b附在此處。
103
此證明雙方在生效日期執行本協議。
Verisign
作者:
姓名：
職稱：
日期：
登記公司名稱:
作者:
姓名：
職稱：
日期: _________________________________
104
附錄8的附件A
註冊費用
1.域名初次註冊費
註冊機構同意按照上述第5.1(b)節所載的通知條款，每年支付美金10.26元的初始域名註冊費，或按照所制定的其他金額。
2.域名續費
註冊機構同意按照上述第5.1(b)節所載的通知條款，每年支付美金10.26元的域名續費，或按照所制定的其他金額。
3.域名轉移
註冊商同意為從其他ICANN認可的註冊商轉移到註冊商的每個域名支付10.26美元，或者根據上述第5.1(b)節中所述的通知條款確定的其他金額。
4.EPP更新以恢復名稱
註冊商同意為使用EPP更新命令恢復域名支付40.00美元，或者根據上述第5.1(b)節中所述的通知條款確定的其他金額。
5.同步
註冊商同意為每次使用支持的協議同步命令支付2.00美元，以及每月1.00美元的同步費，或者根據上述第5.1(b)節中所述的通知條款確定的其他金額。
105
附錄8的展覽b
服務水平協議
請參見.com註冊協議的附錄10，該協議可能會不時修訂。
106
.com註冊協議附錄9
批准的服務
本協議規定了「提議之註冊服務考量程序」。以下註冊服務被具體認定為在生效日期之前已獲得ICANN批准。因此，儘管本協議有其他條款，Verisign可自由部署以下註冊服務：
•根據註冊機構的註冊商參考手冊整合/同步服務；
•國際化域名，根據 Rusty Lewis致Paul Twomey的信 日期為2003年10月13日；
•恢復，允許使用RRP恢復或EPP更新命令在贖回寬限期內檢索以前刪除的域名註冊（經ICANN批准，符合註冊機構的註冊商參考手冊；
•等待名單服務，依據 約翰·O·傑弗里致拉塞爾·路易斯的信 日期為2004年1月26日；
•轉移爭議解決，依據註冊商轉移爭議解決政策，日期為2004年7月12日（可能會被ICANN修訂或替代），以及註冊機構的註冊商轉移爭議補充規則；
•DNS更新服務，依據https://www.icann.org/en/system/files/files/icann-to-verisign-04apr07-en.pdf，日期為2007年4月11日；
•DNSSEC，依據https://www.icann.org/en/system/files/files/icann-to-verisign-2009011-06nov09-en.pdf，日期為2009年11月7日；
•部分投資組合收購後的批量轉移（“BTAPPA”）恢復，依據https://www.icann.org/resources/board-material/minutes-2009-12-09-en，日期為2009年12月9日；
•域名WhoWas，根據https://www.icann.org/en/system/files/files/verisign-whowas-16jul09-en.pdf，日期為2009年7月16日；
•IDN DNS更新，根據https://www.icann.org/en/system/files/files/icann-to-verisign-200906-10jul09-en.pdf，日期為2009年7月10日；
•註冊鎖定服務，根據https://www.icann.org/en/system/files/files/icann-to-verisign-200905-10jul09-en.pdf，日期為2009年7月10日；
•註冊商-註冊人雙重身份驗證服務，根據https://www.icann.org/en/system/files/files/icann-to-verisign-200904-10jul09-en.pdf，日期為2009年7月10日；
•針對可擴展供應協議的驗證碼擴展，根據https://www.icann.org/en/system/files/correspondence/papac-to-kane-27feb17-en.pdf，日期為2017年2月27日；
•依據於2019年3月27日的.COa註冊協議第二修正案，註冊o.com域名，單字符標籤的註冊可在https://itp.cdn.icann.org/en/files/registry-agreements/com/com-amend-2-pdf-27mar19-en.pdf查看；
107
•根據2022年2月14日的文件https://www.icann.org/en/system/files/files/weinstein-to-kane-14feb22-en.pdf，對可擴展配置協議的驗證代碼擴展進行修改；
•根據2022年7月27日的文件https://www.icann.org/en/system/files/correspondence/weinstein-to-orentas-27jul22-en.pdf，雙重身份驗證服務；
•根據2022年9月8日的文件https://www.icann.org/en/system/files/correspondence/weinstein-to-orentas-08sep22-en.pdf，依據相關法律的域名註冊驗證；和
•根據2023年10月25日的文件https://www.icann.org/en/system/files/correspondence/weinstein-to-kane-25oct23-en.pdf，依據相關法律的可擴展配置協議服務及註冊驗證服務。
108
.com登記協議附錄10
服務水平協議(SLA)
VeriSign, Inc. ("登記管理者旨在為其客戶提供世界一流的服務。此服務水平協議（"服務水平協議（SLA））提供補救措施，形式為SLA積分（如第2節所定義），若登記運營商的運行績效低於附錄7中列明的某些績效規範。
1. 定義。
本文中使用的專有名詞，如未另行定義，應按登記協議的定義, 包括但不限於附錄7。
2. SLA積分。
如果登記運營商未能達到附錄7第6節中定義的績效規範，適用於信用等級，則登記運營商應根據所識別的信用等級向ICANN認可的註冊商支付積分，這些積分依據本第2節所述的信用等級表計算（"SLA積分每個ICANN認證註冊商應支付的SLA信貸將作為對註冊和ICANN認證註冊商所欠的其他費用的抵消。SLA信貸代表可能因違反附錄7中規定的性能規範而被評估給註冊運營商的總信貸、罰款和/或責任。所有SLA信貸均應以美金支付。信貸水平表（參見表SLA信貸）指示每個性能規範的相應信貸水平。此SLA將每季度進行對賬，除非此SLA另有規定，否則SLA信貸將每季度發放。
| 附錄7參考 | 性能規範 | SRS | 名稱伺服器 | Whois | ||||||||||
| 6.2.2, 6.2.3, 6.2.4 | 服務可用性 | 第2級 | 第1級 | 第2級 | ||||||||||
| 6.3.1 | 計劃中斷 - 持續時間 | 等級 6 | NA | NA | ||||||||||
| 6.3.2 | 計劃中斷 - 時間範圍 | 等級 5 | NA | NA | ||||||||||
| 6.3.3 | 計劃中停機 - 通知 | 第五級 | NA | NA | ||||||||||
| 6.4.1 | 延長計劃中停機 - 持續時間 | 第六級 | NA | NA | ||||||||||
| 6.4.2 | 延長計劃中停機 - 時間範圍 | 級別 5 | NA | NA | ||||||||||
109
| 6.4.3 | 延長計劃中停機 - 通知 | 級別 5 | NA | NA | ||||||||||
| 6.5.1 | 處理時間 - 檢查域名 | Level 3 | NA | NA | ||||||||||
| 6.5.2 | 處理時間 - 添加/創建域名 | Level 3 | NA | NA | ||||||||||
| 6.5.3 | 處理時間 - 修改/更新及刪除域名 | Level 3 | NA | NA | ||||||||||
| 6.5.4 | 處理時間 - Whois 查詢 | NA | NA | Level 3 | ||||||||||
| 6.5.5 | 處理時間 - DNS 網域名稱伺服器解析 | NA | Level 3 | NA | ||||||||||
| 6.6.1 | 更新頻率 - DNS 網域名稱伺服器 | NA | 4級 | NA | ||||||||||
| 6.6.2 | 更新頻率 - Whois | NA | NA | 4級 | ||||||||||
2.1 信用級別 1 - 信用級別 1 針對每個月時間框架內DNS名稱伺服器服務可用性低於100%進行評估。如果未能達到DNS名稱伺服器服務可用性性能規範，則信用級別1的SLA信貸將在適用日曆月後的30天內支付給活躍的ICANN認可的註冊商。根據本附錄10，所謂的「活躍」ICANN認可註冊商是指在上一個月時間框架內註冊了超過150個淨新增.com域名的註冊商。
每個滿足以下第3節要求的活躍ICANN認可註冊商將獲得一筆金額，該金額等於該活躍ICANN認可註冊商在適用的月份時間框架內註冊的淨新增.com域名數量與所有活躍ICANN認可註冊商在適用月份時間框架內的新.com域名註冊的淨總數之比，乘以表中所列的信用級別1的每月信用金額。
信用等級表 1
| 少於30秒 | 30-60秒 | 1-2分鐘 | 2-10分鐘 | 10-30分鐘 | 超過30分鐘 | |||||||||||||||
| SLA信用金額 | $100,000 | $175,000 | $250,000 | $400,000 | $750,000 | $1,000,000 | ||||||||||||||
2.2 信用等級2 - 信用等級2的評估標準是每個日曆年內SRS服務可用性低於99.99%以及Whois服務可用性低於100%每月的時間範圍。如果服務可用性能績指標未達標，則信用等級2的SLA信用將直接計入符合下面第3節要求的活躍ICANN認可註冊商，金額等於停機持續時間(OT)乘以過去三(3)個月平均每日.com註冊數(NRAvg)再乘以.com批發費用再除以每日分鐘數(1,440分鐘)。
110
活躍ICANN認可註冊商將獲得信用：
（.com 註冊費用）*（OT）*（NRAvg）
（1,440分鐘）
（1,440分鐘）
此外，對於任何月度，如果SRS和Whois的總未計劃停機時間超過30分鐘，註冊機構將向符合下面第3節要求的活躍ICANN認可註冊商支付一千美元（$1,000）。
2.3 信用等級3 - 信用等級3的評估標準是未能滿足檢查域名、添加/創建、修改/更新和刪除域名命令以及DNS名稱伺服器解析和Whois查詢的處理時間性能規範。如果處理時間性能規範的指標未達標，則信用等級3的SLA信用（請參閱信用等級3表格）將根據處理時間超過相應性能規範指標的時間百分比支付給活躍的ICANN認可註冊商。
每個符合下面第3節要求的活躍ICANN認可註冊商將獲得的金額等於該活躍ICANN認可註冊商在適用的月份內的新.net域名註冊總數，除以所有符合條件的活躍ICANN認可註冊商在該月份內的新.net域名註冊總數，再乘以在適用的月份結束後30天內信用等級3表格中所列的SLA信用金額。
信用等級表 3
| 5 - <10% | 10 - <25% | 25 - <50% | ≥50% | |||||||||||
| SLA 信用金額 | $500 | $1,000 | $2,000 | $5,000 | ||||||||||
2.4 信用等級 4 - 信用等級 4 是針對未能滿足 DNS 名稱伺服器和 Whois 更新頻率的性能規範進行評估。如果未能滿足更新頻率的性能規範指標，則根據更新頻率超過適用的性能規範指標的時間百分比，應支付給活躍的 ICANN 認可註冊商的信用等級 4 的 SLA 信用（參見信用等級表 4）。
每個符合下方第 3 節要求的活躍 ICANN 認可註冊商將獲得其在適用的每月時間範圍內的 .com 網域名稱新註冊的淨額等於該活躍 ICANN 認可註冊商的 .com 網域名稱新註冊數量，除以在適用的每月時間範圍內所有活躍 ICANN 認可註冊商的 .com 網域名稱新註冊總數，乘以信用等級表 4 所列的 SLA 信用金額。
信用表第4級
| 高達少於15分鐘 | 15分鐘到少於1小時 | 1小時到少於12小時 | ≥ 12小時 | |||||||||||
| 服務水平協議信用金額 | $500 | $1,000 | $2,000 | $5,000 | ||||||||||
2.5 信用第5級 - 第5級信用是針對未能達到性能規範進行評估
111
針對計劃停機時間框架、計劃停機通知、延長計劃停機時間框架和延長計劃停機通知。如果未滿足性能規範指標，則第5級的服務水平協議信用將支付給符合下面第3節要求的每個活躍的ICANN認可注冊商，金額等於該活躍的ICANN認可注冊商在適用的每月時間框架內的純新.com域名注冊量，與所有活躍的ICANN認可注冊商在適用的每月時間框架內的新.com域名注冊總量的淨額的比值，然後乘以一千美元（$1,000）。
2.6 Credit Level 6 - Credit Level 6 is assessed for failure to meet the Performance Specifications for Planned Outage Duration and Extended Planned Outage Duration. If the Performance Specifications are not met, the SLA Credit for Credit Level 6 shall be payable directly to active ICANN-Accredited Registrar(s) that meet the requirements of Section 3 below in an amount equal to the Average Daily Volume (ADM) of net .com new adds as averaged over the course of the previous three months times the Planned Duration Overage (PDO) in minutes times the SLA Credit graduated financial penalty set forth in Table Credit Level 6. For purposes of this Appendix 10, PDO is calculated by subtracting the maximum allowable time in hours and minutes for a Planned Outage Duration or Extended Planned Outage Duration, as applicable, from the total outage in hours and minutes.
Table Credit Level 6
| 1 to <15 minutes | 15 minutes to <1 hour | 1 to <3 hours | 3 –to <6 hours | ≥ 6 hours | |||||||||||||
| SLA Credit | ADM*PDO*$0.25 | ADM*PDO*$0.5 | ADM*PDO*$1 | ADM*PDO*$1.50 | ADM*PDO*$2 | ||||||||||||
3. 登記機構的責任。
為了使ICANN認可的登記機構可以索取本附錄10中概述的SLA信用，必須嚴格遵循本第3節的程序。
3.1 受影響的ICANN認可登記機構必須報告每次聲稱登記機構運營商未滿足性能規範的事件，並在登記機構運營商要求的方式下（即電子郵件、傳真、電話）向登記機構運營商的客戶服務幫助臺申請SLA信用，以符合申請SLA信用的資格。受影響的ICANN認可登記機構必須在發生未滿足性能規範的日曆年結束後的三個月內提出SLA信用的申請。
3.2 每個ICANN認證的登記機構必須在預測其交易量（不包括檢查域名命令）預計將超過該ICANN認證的登記機構上個月交易量25%時，通知登記運營商。如果ICANN認證的登記機構未能通知登記運營商預測的交易量將增加25%或更多，並且該ICANN認證的登記機構的交易量相較上個月增加25%或更多，而該月份所有ICANN認證登記機構的登記運營商的總交易量超過登記運營商上個月的實際交易量20%，則該ICANN-
112
認證的登記機構將不具備在該每月時間範圍內獲得本SLA中概述的任何SLA信貸的資格。ICANN認證的登記機構應至少在相關日曆月份的第一天之前30天提供此預測。登記運營商同意通過電子郵件向ICANN認證的登記機構提供每月交易摘要報告。
3.3 受影響的ICANN認證登記機構必須提供支持其索賠SLA信貸的文件。ICANN認證的登記機構應以以下任一形式提供文件：
a) ICANN認證的登記機構發起的通知，告知登記運營商性能規範超出SLA限制或未能滿足SLA要求，包括登記運營商發出故障票號。關閉票據應包括在內，以確定總停機時間（除非故障票包含此信息）；或
b) 登記運營商的通知（附故障票號），告知性能規範超出SLA限制或未能滿足SLA要求。關閉票據應包括在內，以確定總停機時間（除非故障票包含此信息）。
3.4 為了計算信貸，受影響的ICANN認證登記機構必須包括過去三（3）個日曆月的交易量數據（或如果時間更少，則為該ICANN認證登記機構被授權註冊.com登記處域名的時間），並提供證明，證明這些數據準確反映在受影響期間內將涵蓋的最小註冊數。
3.5 登記機構應進行所需的測量，以證實ICANN認可的註冊商所要求的總SLA信用額度。這些測量及相關文件應通過電子郵件發送給每個要求SLA信用的ICANN認可註冊商。
3.6 當上述步驟準確完成後，登記機構應通知受影響的ICANN認可註冊商，其帳戶中將輸入可立即用於.com域名註冊及ICANN認可註冊商需支付給登記機構的其他費用的SLA信用數量。
4. 責任。
4.1 除了跨網絡名稱伺服器性能的情況（這不是本服務水平協議的主題）外，登記機構將從至少兩個外部位置和至少一個內部位置進行監控，以驗證：a）會話可以有效建立，b）EPP命令可以成功完成。
4.2 如果所有ICANN認可的註冊商都受到SRS無法使用的影響，則登記機構有責任開立一個總體故障票，並立即通知所有ICANN認可的註冊商故障票號及詳細信息。
4.3 如果系統服務對某個ICANN認可的註冊商無法使用，登記機構將盡商業上合理的努力，儘快重新建立該ICANN認可註冊商受影響的系統服務。任何歸因於任何個別ICANN認可註冊商的系統服務無法使用，
113
不代表系統服務中斷的情況將不會導致SLA信用或受到本SLA的約束。
4.4 ICANN認可的註冊商與登記機構同意以合理的商业善意努力確定任何所謂系統服務無法使用的原因。如果共同確定是登記機構的問題，則系統服務的無法使用將受到本SLA的約束。
4.5 登記機構將在不可抗力事件結束後的24小時內，儘商業上合理的努力恢復任何系統服務，並在不可抗力事件結束後的48小時內恢復完整的系統功能。因不可抗力造成的中斷將不被視為系統服務不可用，不影響附錄7中規定的性能規範，或受此SLA約束。
4.6 登記機構將在商業上合理的時間內開立事件故障票，並將按嚴重程度逐級處理所有系統性能問題，並在商業上合理的時間內修復。由度量系統標記的事件也將視為票據事件，並受此SLA約束。
4.7 登記機構將每月發布系統性能和服務可用性報告。
5. 其他事項。
5.1 本SLA獨立於登記協議中規定的任何權利、義務或職責。在本SLA的條款與條件與登記協議之間發生任何衝突的情況下，應以登記協議為主。
5.2 本SLA作為登記-登記機構協議（"RRA"）的附錄，不意圖替代RRA中的任何條款或條件。
5.3 爭議解決將根據RRA第6.7節處理。
5.4 任何直接因RRA第2.13節（技術問題或協議違約的解決）、第5.4節（未支付費用）或第6.3節（不可抗力）或RRA中任何其他適用條款造成的系統服務中斷將不受此SLA約束，但僅在該系統服務中斷因登記機構遵守上述RRA條款或自生效日期後制定的任何共識政策而無法以商業上合理的努力避免的情況下適用。
114
.com 登記協議附錄 11
公共利益承諾
登記運營商同意履行以下公共利益承諾。
a.登記運營商將確保在其登記-登記商協議中有一項條款，要求登記商在其註冊協議中包括一項禁止登記名稱持有者分發惡意軟件、濫用運行機器人網絡、網絡釣魚、盜版、商標或版權侵權、欺詐或誤導性行為、偽造或以其他方式從事與適用法律相抵觸的活動，並根據適用法律及任何相關程序，對此類活動提供後果（由相關的登記商根據其登記商認證協議執行），包括暫停域名。
b.登記運營商將定期，但至少每月進行一次，進行技術分析，以評估域名系統（TLD）中的域名是否被用於實施DNS濫用。登記運營商將保持有關已識別DNS濫用及因此而採取的行動的統計報告。登記運營商將在協議的當前期限內保持這些報告，除非法律要求的期限較短或ICANN批准，並會在要求時提供給ICANN。
c. DNS濫用緩解. 當登記運營商根據可行的證據合理確定，TLD中的註冊域名被用於DNS濫用時，登記運營商必須迅速採取適當的緩解行動，這些行動在合理上是必要的，以幫助停止或以其他方式中斷該域名被用於DNS濫用。這些行動至少應包括：（i）將被用於DNS濫用的域名及相關證據轉發給贊助登記商；或（ii）在登記運營商認為適當的情況下，直接採取行動。行動可能根據每個案例的情況有所不同，考慮到從DNS濫用造成的傷害的嚴重性及可能的相關損害。根據本協議，“DNS濫用”定義為惡意軟件、機器人網絡、網絡釣魚、藥物欺詐和垃圾郵件（當垃圾郵件作為其他形式的DNS濫用的傳遞機制時），根據SAC115（2021年3月19日）第2.1節中所定義的條款<u003chttps://www.icann.org/en/system/files/files/sac-115-en.pdf>）。
d. 事件報告. 登記管理者將在發現有任何網絡事件、實體入侵或對TLD登記系統基礎設施造成損害後的七十二（72）小時內通知ICANN，這些事件顯著危及或有合理可能顯著危及登記系統的完整性、機密性或可用性，例如：
115
意外或非法破壞、丟失、改變、未經授權披露或訪問登記帳戶信息、註冊數據、DNSSEC加密私鑰或其他對登記系統運作至關重要的信息資產。根據本節要求的通知應該包括，在登記管理者經合理調查後所知的情況下，對網絡事件、實體入侵或基礎設施損害的詳細說明，包括發生的方式、受影響的登記系統、對登記商或登記人可能產生的影響（如有）、受影響的登記商、域名和登記人的數量，以及登記管理者對網絡事件、實體入侵或基礎設施損害所採取的行動。如果此類信息最初不可用，登記管理者應在不造成不當延遲的情況下，當該信息可用時提供。ICANN不應以任何方式披露根據本節所發出的通知，除非事先獲得登記管理者的書面同意，或法律要求或為了保護互聯網的安全、穩定和韌性，在這種情況下，ICANN的披露應限於相關的權威機構或機構。
e. 網絡進入過濾登記管理者應根據BCP 38和BCP 84實施其登記服務的網絡進入過濾檢查，ICANN也將實施該措施。
116