Internet Engineering Task Force H. Wu Internet Draft J. Chen Intended status: Experimental X. Fan Expires: December 21 2022 Z. Li China Academy of Information and Communications Technology J. Xie June 16, 2022 Industrial Internet Identifier Data Escrow Interface draft-wu-identifier-data-escrow-interface-05 Abstract This document describes the Data Escrow report requirement and technical details of the interfaces provides by the Top-level Node (TLN) to its contracted parties. Second-level Node (SLN) MUST periodically send data escrow report to Top-level Node (TLN) and Data Escrow Agent (DEA). DEA MUST sends report verify result to TLN and SLN after processing the report. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 20, 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Expires December 20, 2022 [Page 1] Internet-Draft IIIN-Data-Escrow December 2022 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................ 3 2. Conventions ................................................. 3 3. Data Escrow Requirement...................................... 4 3.1. Deposits ............................................... 4 3.2. Escrow Format .......................................... 4 3.3. Schedule for Deposits................................... 4 3.4. File Naming Conventions................................. 4 3.5. Processing of Deposits files............................ 5 3.6. Distribution of Public Keys............................. 6 3.7. Notification of Deposits................................ 6 3.8. Verification Procedure.................................. 7 3.9. Verification of Deposits................................ 7 4. Object Description .......................................... 8 4.1. Object................................... 8 4.2. Object.............................. 8 4.3. Element................ 10 4.4. Object........................... 11 4.5. Object........................... 13 4.6. Object............... 13 5. Interfaces for Data Escrow Reporting........................ 14 5.1. SLN Reporting ......................................... 14 5.2. Data Escrow Agent Reporting............................ 15 6. Technical details of the interfaces......................... 17 6.1. Response Object........................................ 18 6.1.1. SLN Reporting..................................... 20 6.1.2. Data Escrow Agent Reporting....................... 20 7. Monitoring the reporting status............................. 22 7.1. Monitoring the status of Repository Reports............ 22 7.2. Monitoring the status of Data Escrow Reports........... 22 7.3. Monitoring the status of Data Escrow Notifications..... 23 8. Formal Syntax .............................................. 23 8.1. Result Object ......................................... 23 8.2. Report Object ......................................... 26 8.3. Notification Object.................................... 28 8.4. Summary Object ........................................ 31 8.5. Reports Object ........................................ 35 8.6. Notifications Object................................... 37 Wu, et al. Expires December 20, 2022 [Page 2] Internet-Draft IIIN-Data-Escrow December 2022 9. Internationalization Considerations......................... 39 10. Security Considerations.................................... 39 11. IANA Considerations........................................ 39 12. Privacy Considerations..................................... 40 13. References ................................................ 40 13.1. Normative References.................................. 40 14. Acknowledgments ........................................... 41 1. Introduction This document describes the Data Escrow report requirement and technical details of the interfaces provides by the Top-level Node (TLN) to its contracted parties. Second-level Node (SLN) MUST periodically send data escrow report to Top-level Node (TLN) and Data Escrow Agent (DEA). DEA MUST sends report verify result to TLN and SLN after processing the report. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. TOP-LEVEL NODE (TLN).In the context of this draft the definition will indicate an organization providing Registry Services for a top level identifier. TLN also provide Second-level Node manager services. SECOND-LEVEL NODE (SLN). In the context of this draft the definition will indicate an organization providing Registry Services for a second level identifier. Data Escrow Agent. The organization designated by the SLN to receive and guard data escrow deposits from the SLN. Date and Time. Numerous fields indicate "dates", such as the creation and expiry dates for objects. These fields SHALL contain timestamp indicating the date and time in UTC, specified in Internet Date/Time Format (see [RFC3339], Section 5.6) with the time-offset specified as "Z". XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation. Wu, et al. Expires December 20, 2022 [Page 3] Internet-Draft IIIN-Data-Escrow December 2022 3. Data Escrow Requirement SLN MUST engage an independent entity to act as data escrow agent for the provision of data escrow services. The following sections define the data escrow requirement. 3.1. Deposits There will be two types of Deposits: Full and Differential. o Full Deposit will consist of data that reflects the state of the SLN as of 00:00:00 UTC (Coordinated Universal Time) on the day that such Full Deposit is submitted to Escrow Agent. o Differential Deposit means data that reflects all transactions that were not reflected in the last previous Full or Differential Deposit, as the case may be. Each Differential Deposit will contain all database transactions since the previous Deposit was completed as of 00:00:00 UTC of each day. 3.2. Escrow Format Deposit's Format. SLN will include identifier node elements described in draft-industrial-internet-identifier-data-escrow (IIIDE) and draft-second-level-node-objects-mapping (SLNOM) in the Deposits. If IIIDE and SLNOM not already an RFC, SLN will use the most recent draft version of the IIIDE and SLNOM available at the Effective Date. Once the IIIDE and SLNOM is published as a RFC, SLN will implement that version of the IIIDE and SLNOM Specification, no later than one hundred eighty calendar days after. 3.3. Schedule for Deposits SLN will submit a set of escrow files on a daily basis as follows: o Each Sunday, a Full Deposit must be submitted to the Escrow Agent by 23:59 UTC. o The other six (6) days of the week, a Full Deposit or the corresponding Differential Deposit must be submitted to Escrow Agent by 23:59 UTC. 3.4. File Naming Conventions Data Escrow Deposit Files will be named according to the following convention: Wu, et al. Expires December 20, 2022 [Page 4] Internet-Draft IIIN-Data-Escrow December 2022 {Snode}_{YYYY-MM-DD}_{type}_S{#}_R{rev}.{ext} o {Snode} is replaced with the SLN prefix. o {YYYY-MM-DD} is replaced by the date corresponding to the time used as a timeline watermark for the transactions. o {type} is replaced by: "full", if the data represents a Full Deposit; "diff", if the data represents a Differential Deposit; o {#} is replaced by the position of the file in a series of files, beginning with "1"; in case of a lone file, this must be replaced by "1". If it is a report file, there is no S{#}. o {rev} is replaced by the number of the revision(or resend) of the file beginning with "0". o {ext} replaced by the "inde", Replaced by the "sig" if it is a digital signature file, replaced by the "rep" if it is a report file. 3.5. Processing of Deposits files The use of compression is recommended in order to reduce electronic data transfer times, and storage capacity requirements. Data encryption will be used to ensure the privacy of registry escrow data. Files processed for compression and encryption will be in the binary OpenPGP format as per OpenPGP Message Format. The process to follow for the data file in original text format is: 1) Compress the data file(s). According to RFC 4880, the recommended compression algorithm is zip. 2) A compressed and encrypted OpenPGP Message is created using the tarball file as sole input. The suggested algorithm for compression is ZIP as per RFC 4880. The compressed data will be encrypted using the escrow agent's public key. The suggested algorithms for Public-key encryption are Elgamal and RSA as per RFC 4880. The suggested algorithms for Symmetric-key encryption are TripleDES, AES128 and CAST5 as per RFC 4880. 3) The file may be split as necessary if, once compressed and encrypted, it is larger than the file size limit agreed with the Wu, et al. Expires December 20, 2022 [Page 5] Internet-Draft IIIN-Data-Escrow December 2022 escrow agent. Every part of a split file, or the whole file if not split, will be called a processed file in this section. 4) A digital signature file will be generated for every processed file using the SLN private key. The digital signature file will be in binary OpenPGP format, and will not be compressed or encrypted. The suggested algorithms for Digital signatures are DSA and RSA as per RFC 4880. The suggested algorithm for Hashes in Digital signatures is SHA256. 5) The processed files and digital signature files will then be transferred to the Escrow Agent through secure electronic mechanisms, such as, SFTP, SCP, HTTPS file upload, etc. 6) The Escrow Agent will then validate every (processed) transferred data file using the procedure described in Section 3.8. 3.6. Distribution of Public Keys Each of SLN and Escrow Agent will distribution this public key to the other party via email to an email address to be specified. Each party will confirm receipt of the other party's public key with a reply email, and the distributing party will subsequently reconfirm the authenticity of the key transmitted via offline methods, like in person meeting, telephone, etc. In this way, public key transmission is authenticated to a user able to send and receive mail via a mail server operated by the distributing party. Escrow Agent, SLN and TLN will exchange public keys by the same procedure. 3.7. Notification of Deposits Along with the delivery of each Deposit, SLN will deliver to Data Escrow Agent and TLN a written statement that includes a copy of the report generated upon creation of the Deposit and states that the Deposit has been inspected by SLN and is complete and accurate. The preparation and submission of this statement must be performed by the SLN or its designee, provided that such designee may not be the Escrow Agent or any of Escrow Agent's Affiliates. SLN will include the Deposit's "id" and "resend" attributes in its statement. The attributes are explained in IIIDE and SLNOM. The written statement file is submitted to the TLN by calling the data escrow interfaces provided by TLN. The written statement file, data escrow file and digital signature file are transmitted to DEA through security electronic mechanisms (for example, SFTP, SCP, HTTPS file upload, etc.). Wu, et al. Expires December 20, 2022 [Page 6] Internet-Draft IIIN-Data-Escrow December 2022 The Data Escrow Agent receives the deposit and verifies it. Every time it verifies a deposit, it must send the verification results to SLN and TLN. The verification results file is submitted to the TLN by calling the data escrow interfaces provided by TLN. The verification results file transmitted to SLN by verified email. When the SLN fails to send the deposit file within the time limit specified in the deposit schedule, the Data Escrow Agent needs to notify the SLN via verified email. 3.8. Verification Procedure o The signature file of each processed file is validated. o If processed files are pieces of a bigger file, the latter is put together. o Each file obtained in the previous step is then decrypted and uncompressed. o Each data file contained in the previous step is then validated against the format. o The data escrow agent extended verification process as well as any other data escrow verification process contained in such reference. If any discrepancy is found in any of the steps, the Deposit will be considered incomplete, and must complete this data escrow before the next data escrow time specified 3.9. Verification of Deposits o Within twenty-four hours after receiving each Deposit or corrected Deposit, DEA must verify the format and completeness of each Deposit and deliver to TLN and SLN a notification generated for each Deposit. o If DEA discovers that any Deposit fails the verification procedures or if DEA does not receive any Scheduled Deposit, DEA must notify SLN and TLN either by email, fax or phone. Upon notification of such verification or delivery failure, SLN must begin developing modifications, updates, corrections, and other fixes of the Deposit necessary for the Deposit to be delivered and pass the verification procedures and deliver such fixes to DEA and TLN as promptly as possible. Wu, et al. Expires December 20, 2022 [Page 7] Internet-Draft IIIN-Data-Escrow December 2022 4. Object Description This section describes the base objects supported by this specification: 4.1. Object The TLN interfaces for SLN and data escrow agents object is used to provide information on the result of a verification process when interacting with the interfaces. The object contains the following attribute and child elements: o A "code" attribute whose value is a four-digit decimal number that identifies the result of a process. Available result code values MUST be defined for the corresponding process. o An OPTIONAL "count" attribute to indicate the number of industry internet identifier node object related to the reported result. o A element containing a human-readable description of the result code. o An OPTIONAL element that includes additional details on the result conditions. An example of a object is presented below: The structure of the report is invalid. 'XXX' could not be parsed as a number 4.2. Object The contents of a data escrow deposit are described using a object. The object contains the following child elements: Wu, et al. Expires December 20, 2022 [Page 8] Internet-Draft IIIN-Data-Escrow December 2022 o An element that contains the identifier assigned to this report. The report identifier MUST be the same as the "id" attribute from the . If the data escrow deposit does not include a unique identifier, the Data Escrow Agent MUST generate a unique identifier to reference the data escrow deposit and use it in the element. o A element contains the version of the specification used. This value MUST be 1. o A element contains the version of the Data Escrow Specification (e.g. draft-caict-industrial-internet- identifier-data-escrow-00) used to create the deposit. After the specification is published as an RFC, the value MUST be the RFC number assigned by IANA. o An OPTIONAL element contains the version of the Identifier Node Registration Data (INRD) Objects Mapping (e.g. draft-second-level-node-objects-mapping-00) used to create the deposit. After the specification is published as an RFC, the value MUST be the RFC number assigned by IANA. The element MUST be included if the deposit was created using any version of the INRD objects mapping specification. o A element contains the value of the "resend" attribute of the . o A element contains the date and time that the deposit was created by the SLN. o A element is used to identify the kind of deposit: FULL, or DIFF (Differential). o A element contains the date and time corresponding to the Timeline Watermark ( element) of the . o A element contains the header of the as defined in [draft-second-level-node-objects- mapping]. An example of a object is available in Section 5.1. Wu, et al. Expires December 20, 2022 [Page 9] Internet-Draft IIIN-Data-Escrow December 2022 4.3. Element The object is used by Data Escrow Agents to document the result of the data escrow deposit verification process. The object contains the following child elements: o A element contains the name of the Data Escrow Agent. o A element contains the version of the specification used. This value MUST be 1. o A element contains the reported date. In case of a DVPN or DVFN notification this value MUST be the date of the element of the . In case of a DRFN deposit notification, this value MUST be the date for which no deposit was received from SLN. o A element is used to specify the status of . The possible values of status are: DVPN, DVFN and DRFN. The value for the element is determined by the three types of notices:: Deposit Receipt Failure Notice (DRFN): generated by the Data Escrow Agent when no deposit is received pursuant to the data escrow deposit schedule. Deposit Verification Failure Notice (DVFN): generated by the Data Escrow Agent when a deposit is received, but the final result of the verification process is failure. Deposit Verification Pass Notice (DVPN): generated by the Data Escrow Agent when a deposit is received and the final result of the verification process is success. o An OPTIONAL element contains the errors detected during the data escrow deposit verification process performed by the Data Escrow Agent. The element includes one or more elements as defined in Section 4.1. In case of a DRFN or DVPN deposit notification the element MUST NOT be present. o An OPTIONAL element contains the date and time that the deposit was successfully received by the Data Escrow Agent. In case of a DRFN deposit notification this element MUST NOT be present. Wu, et al. Expires December 20, 2022 [Page 10] Internet-Draft IIIN-Data-Escrow December 2022 o An OPTIONAL element contains the date and time that the deposit was processed for validation by the Data Escrow Agent. In case of a DRFN deposit notification this element MUST NOT be present. o An OPTIONAL element contains the date of the Timeline Watermark ( element) of the most recent FULL deposit that was successfully validated by the Data Escrow Agent. This element MUST NOT be present if a successfully validated full deposit has never been deposited. o An OPTIONAL element is used by the Data Escrow Agent to provide extended information about the deposit. In case of a DRFN deposit notification this element MUST NOT be present. In case of a DVPN or DVFN deposit notification this element MUST be present. When this element is present, the element MUST be generated by the Data Escrow Agent for the Timeline Watermark ( element) of the deposit being processed. If the deposit being processed is a differential deposit, the Data Escrow Agent MUST process the last full plus all differentials escrow deposits from the same repository to generate the element. o Note: In case of a DVPN or DVFN deposit notification, the is used as unique identifier. An example of a object is available in Section 5.2. 4.4. Object Interfaces that support monitoring the reporting status for a specific repository, provide a object as defined by the schema in Section 6 in the HTTP Entity-body when a HTTP/200 code is sent by the interface. The element includes the following child elements: o A choice of one of the elements as defined in the "indeHeader:repositoryTypeGroup" (see [draft-second-level-node- objects-mapping]) that indicates the unique identifier for the repository being escrowed. o A element with the date and time in which the queried repository was created in the system. Wu, et al. Expires December 20, 2022 [Page 11] Internet-Draft IIIN-Data-Escrow December 2022 o A OPTIONAL element indicating the current Data Escrow Deposit schedule for the queried repository. Possible values are "None", "Weekly", and "Daily". o An OPTIONAL element indicating the date of the Timeline Watermark ( element) of the most recent FULL deposit that was successfully validated for the queried repository as notified by the Data Escrow Agent. o A element with a element for each report type for the queried repository. Each element includes the following child elements: : a string value indicating the report type to which the information provided pertains. : a Boolean value indicating if the report type is enabled for the repository. : a string value indicating the reporting status. A value of "ok" indicates there are no reporting issues in the corresponding report type, otherwise the value of "unsatisfactory" is shown. An OPTIONAL element included only when the element has a value of "unsatisfactory", and includes an empty element for each date with a reporting problem found in the corresponding report type. Each element includes a REQUIRED "date" attribute in "YYYY-MM-DD" format and a REQUIRED "description" attribute to describe the issue. The possible values to describe each reporting issue are: "Missing_Deposit_Full": If the latest notification received from the Data Escrow Agent for the date indicates that a scheduled "Full" deposit was not submitted by the repository owner. "Missing_Deposit_Diff": If the latest notification received from the Data Escrow Agent for the date indicates that a scheduled "Differential" deposit was not submitted by the repository owner. "Invalid_Deposit_Full": If the latest notification received from the Data Escrow Agent for the date indicates that a "Full" deposit was received by the Data Escrow Agent, but failed the verification process. Wu, et al. Expires December 20, 2022 [Page 12] Internet-Draft IIIN-Data-Escrow December 2022 "Invalid_Deposit_Diff": If the latest notification received from the Data Escrow Agent for the date indicates that a "Differential" deposit was received by the Data Escrow Agent, but failed the verification process. "No_Report_Received" If no report has been received for the date. o A element to indicate the date and time in which the reporting status response was created. 4.5. Object Interfaces that support monitoring and retrieving Data Escrow Reports received, provide a object in the HTTP Entity-body when a HTTP/200 code is sent by the interface. The element includes a list of objects, one for each successfully received by TLN. Each object includes the following child elements: o A element to indicate the date and time in which the report was received by TLN. o A element as defined in Section 4.2. 4.6. Object Interfaces that support monitoring and retrieving Data Escrow Notifications received from Data Escrow Agents, provide a object in the HTTP Entity-body when a HTTP/200 code is sent by the interface. The element includes a list of objects, one for each successfully received by TLN. Each object includes the following child elements: o A element to indicate the date and time in which the notification was received by TLN. o A element as defined in Section 4.3. Wu, et al. Expires December 20, 2022 [Page 13] Internet-Draft IIIN-Data-Escrow December 2022 5. Interfaces for Data Escrow Reporting This section describes the interfaces provided by TLN to SLN and Data Escrow Agents in order to fulfill the reporting requirements. 5.1. SLN Reporting In order to satisfy the Section 3.7 requirement, the SLN sends to TLN and Data Escrow Agent a object as defined Section 4.2 for each deposit successfully sent to the Data Escrow Agent, using the PUT HTTP verb in the interface provided by TLN at: https://inde-api.caict.ac.cn/report/sln-escrow-report// where: o MUST be substituted by the SLN Prefix for which the report is being provided. o MUST be substituted by the identifier assigned to this report, which MUST be the same as the "id" attribute from the . Note: the interface supports overwriting the information of a particular report to support asynchronous interfaces between SLN and Data Escrow Agents. Example of a object for a data escrow deposit corresponding to a SLN Prefix repository: 2020117001 1 draft-industrial-internet-identifier-data-escrow-00 Wu, et al. Expires December 20, 2022 [Page 14] Internet-Draft IIIN-Data-Escrow December 2022 draft-second-level-node-objects-mapping-00 0 2020-01-17T00:15:00.0Z FULL 2020-01-17T00:00:00Z 86.100 2 5.2. Data Escrow Agent Reporting This Specification requires Data Escrow Agents to deliver TLN and SLN with a notification object every time a successfully processed deposit is received from the SLN regardless of the final status of the verification process. In order to satisfy this requirement, the Data Escrow Agent sends to TLN and SLN a object as defined in Section 4.3, using the POST HTTP verb in the interface provided by TLN at: https://inde-api.caict.ac.cn/report/escrow-agent-notification/ Where: o MUST be substituted by the SLN Prefix for which the notification is being provided. Wu, et al. Expires December 20, 2022 [Page 15] Internet-Draft IIIN-Data-Escrow December 2022 If by 23:59:59 UTC, a deposit has not been successfully processed regardless of the final status of the verification process, a object with DRFN status MUST be send to TLN and SLN. Example of a object of a Data Escrow Agent notification: CAICT Data Escrow Agent. 1 2020-01-17 DVPN 2020-01-17T00:15:00.0Z 2020-01-17T05:15:00.0Z 2020-01-10 20200117001 1 draft-industrial-internet-identifier-data-escrow-00 Wu, et al. Expires December 20, 2022 [Page 16] Internet-Draft IIIN-Data-Escrow December 2022 draft-second-level-node-objects-mapping-00 0 2020-01-17T00:15:00.0Z FULL 2020-01-17T00:00:00Z 86.100 1 6. Technical details of the interfaces Content-type value in the HTTP header: The client MUST set "text/xml" in the HTTP header Content-type when using the SLN Reporting and Data Escrow Agent Reporting interfaces. The interfaces support HTTP streams only (HTTP multi-part forms are not supported) After successfully receiving an input in any of the interfaces, TLN validates it and provides a object with a result element in the same HTTP transaction. The following HTTP status codes are standard across all interfaces: Wu, et al. Expires December 20, 2022 [Page 17] Internet-Draft IIIN-Data-Escrow December 2022 o The interface provides a HTTP/200 status code and sets the HTTP header Content-type: text/xml, if the interface was able to receive the input successfully, the client MUST review the response object to verify the result code after processing the input. o The interface provides a HTTP/400 status code and sets the HTTP header Content-type: text/xml, if the input is incorrect or the syntax of the input is invalid. A response object is included with the input validation failure details. o The interface provides a HTTP/401 status code and sets the HTTP header Content-type: text/plain, if the credentials provided does not authorize the SLN to upload a report for that . o The interface provides a HTTP/403 status code and sets the HTTP header Content-type: text/plain, if the credentials provided are valid but are being used to access a resource that permission is not granted for or the connecting IP address is not whitelisted for the . o The interface provides a HTTP/405 status code if the interface does not support the request method. o The interface provides a HTTP/500 status code and sets the HTTP header Content-type: text/plain, if the system is experiencing a general failure. The sending party is responsible to send the input again. o The interface provides a HTTP/501 status code and sets the HTTP header Content-type: text/plain, if the functionality has not yet been implemented. After sending the response, the interfaces closes the TCP connection 6.1. Response Object After processing the input provided in any of the interfaces, a response object as defined in section 4.1 is provided in the HTTP Entity-body when an HTTP/200 or HTTP/400 status code is sent by the interface. An example of a response object upon successful input receipt is presented below: HTTP/1.1 200 OK Wu, et al. Expires December 20, 2022 [Page 18] Internet-Draft IIIN-Data-Escrow December 2022 Content-Type: text/xml Content-Length: 246 No ERRORs were found and the report has been accepted by TLN. An example of a response object in the event of input error is presented below: HTTP/1.1 400 Bad Request Content-Type: text/xml Content-Length: 279 The structure of the report is invalid. 'XX' could not be parsed as a number (line: 2 column:3) Wu, et al. Expires December 20, 2022 [Page 19] Internet-Draft IIIN-Data-Escrow December 2022 The following sections provide the Result Codes per interface: 6.1.1. SLN Reporting The following table lists the result codes of the interface: Result Code Message 1000 No ERRORs were found and the report has been accepted by TLN. 2001 The request did not validate against the schema. 2002 Report for a date in the future. The and date should not be in the future. 2003 Version is not supported. 2004 The in the element and the in the URL path do not match. 2005 Interface is disabled for this SLN Prefix. 2006 The and date should not be before the creation date of the prefix in the system. 2201 The in the
and the SLN Prefix in the URL path do not match. 2202 Report regarding a differential deposit received for a Sunday (). 2203 Missing required element in the
. 2204 Multiple count elements with the same "uri" attribute values provided in the
. 6.1.2. Data Escrow Agent Reporting The following table lists the result codes of the interface: Wu, et al. Expires December 20, 2022 [Page 20] Internet-Draft IIIN-Data-Escrow December 2022 Result Code Message 1000 No ERRORs were found and the notification has been accepted by TLN. 2001 The request did not validate against the schema. 2002 Notification for a date in the future. The , and date should not be in the future. 2003 Version is not supported. 2004 A DVPN notification exists for that date (). 2005 Interface is disabled for this SLN Prefix. 2006 The , and date should not be before the creation date of the SLN Prefix in the system. 2007 The and in the notification do not match. 2201 The in the
and the SLN Prefix in the URL path do not match. 2202 Notification regarding a differential deposit received for a Sunday (). 2203 Missing required element in the
. 2204 Multiple count elements with the same "uri" attribute values provided in the
. 2205 The notification for the report "id" already exists. 2206 A Deposit Verification Pass Notice (DVPN) notification was received, but the Domain Name count is missing in the
. 2207 A DVPN or DVFN was received, but the element is missing in the notification. Wu, et al. Expires December 20, 2022 [Page 21] Internet-Draft IIIN-Data-Escrow December 2022 2208 A DRFN was received, but a element exists in the notification. 7. Monitoring the reporting status SLNs May monitor the status of the reports described in Chapter 3 using the following interfaces that supports the HEAD HTTP verb: 7.1. Monitoring the status of Repository Reports SLNs May monitor the status of repository using the following interface: https://inde-api.caict.ac.cn/info/report/sln-escrow- repository/ where: o MUST be substituted by the SLN Prefix being queried. Possible results are: o The interface provides a HTTP/200 status code, if syntactically valid data escrow reports was received for the queried prefix. o The interface provides a HTTP/404 status code, if syntactically valid data escrow reports has not been received for the queried prefix. 7.2. Monitoring the status of Data Escrow Reports SLNs May monitor the status of Data Escrow Reports using the following interface: https://inde-api.caict.ac.cn/info/report/sln-escrow- report// where: o MUST be substituted by the SLN Prefix being queried. o MUST be substituted by the day being queried. For example: 2020-01-07 Wu, et al. Expires December 20, 2022 [Page 22] Internet-Draft IIIN-Data-Escrow December 2022 Possible results are: o The interface provides a HTTP/200 status code, if a syntactically valid data escrow report was received for the queried date. o The interface provides a HTTP/404 status code, if a syntactically valid data escrow report has not been received for the queried date. 7.3. Monitoring the status of Data Escrow Notifications SLNs and Data Escrow Agents May monitor the status of Data Escrow Notifications using the following interface: https://inde-api.caict.ac.cn/info/report/escrow-agent- notification// where: o MUST be substituted by the SLN Prefix being queried. o MUST be substituted by the day being queried. For example: 2020-01-07 Possible results are: o The interface provides a HTTP/200 status code, if a syntactically valid data escrow notification was received for the queried date. o The interface provides a HTTP/404 status code, if a syntactically valid data escrow notification has not been received for the queried date. 8. Formal Syntax The schema of the Result, Report, Notification, Summary, Reports, and Notifications objects described in Chapter 4 are presented here. The BEGIN and END tags are not part of the schema; they are used to note the beginning and ending of the schema for URI registration purposes. 8.1. Result Object Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved. Wu, et al. Expires December 20, 2022 [Page 23] Internet-Draft IIIN-Data-Escrow December 2022 Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. o Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. o Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. BEGIN TLN interfaces for SLNs and data escrow agents Wu, et al. Expires December 20, 2022 [Page 24] Internet-Draft IIIN-Data-Escrow December 2022 Wu, et al. Expires December 20, 2022 [Page 25] Internet-Draft IIIN-Data-Escrow December 2022 END 8.2. Report Object Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. o Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. o Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. BEGIN Data Escrow Report schema Wu, et al. Expires December 20, 2022 [Page 27] Internet-Draft IIIN-Data-Escrow December 2022 END 8.3. Notification Object Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. o Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. o Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. BEGIN Wu, et al. Expires December 20, 2022 [Page 28] Internet-Draft IIIN-Data-Escrow December 2022 Data Escrow Notification schema Wu, et al. Expires December 20, 2022 [Page 29] Internet-Draft IIIN-Data-Escrow December 2022 Wu, et al. Expires December 20, 2022 [Page 30] Internet-Draft IIIN-Data-Escrow December 2022 END 8.4. Summary Object Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. o Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. o Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. BEGIN Wu, et al. Expires December 20, 2022 [Page 32] Internet-Draft IIIN-Data-Escrow December 2022 Wu, et al. Expires December 20, 2022 [Page 33] Internet-Draft IIIN-Data-Escrow December 2022 Wu, et al. Expires December 20, 2022 [Page 34] Internet-Draft IIIN-Data-Escrow December 2022 END 8.5. Reports Object Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. o Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. o Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; Wu, et al. Expires December 20, 2022 [Page 35] Internet-Draft IIIN-Data-Escrow December 2022 LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. BEGIN Wu, et al. Expires December 20, 2022 [Page 36] Internet-Draft IIIN-Data-Escrow December 2022 END 8.6. Notifications Object Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. o Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. o Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. BEGIN END Wu, et al. Expires December 20, 2022 [Page 38] Internet-Draft IIIN-Data-Escrow December 2022 9. Internationalization Considerations Data escrow deposits are represented in XML, which provides native support for encoding information using the Unicode character set and its more compact representations including UTF-8. Conformant XML processors recognize both UTF-8 and UTF-16. Though XML includes provisions to identify and use other character encodings through use of an "encoding" attribute in an declaration, use of UTF-8 is RECOMMENDED. 10. Security Considerations This specification does not define the security mechanisms to be used in the transmission of the data escrow deposits, since it only specifies the minimum necessary to enable the rebuilding of an IIIN from deposits without intervention from the original IIIN. Depending on local policies, some elements or most likely, the whole deposit will be considered confidential. As such the IIIN transmitting the data to the escrow agent SHOULD take all the necessary precautions like encrypting the data itself and/or the transport channel to avoid inadvertent disclosure of private data. It is also of the utmost importance the authentication of the parties passing data escrow deposit files. The escrow agent SHOULD properly authenticate the identity of the IIIN before accepting data escrow deposits. In a similar manner, the IIIN SHOULD authenticate the identity of the escrow agent before submitting any data. Additionally, the IIIN and the escrow agent SHOULD use integrity checking mechanisms to ensure the data transmitted is what the source intended. Validation of the contents by the escrow agent is RECOMMENDED to ensure not only the file was transmitted correctly from the IIIN, but also the contents are also "meaningful". 11. IANA Considerations This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. Twelve URI assignments need to be registered by the IANA. Registration request for the INDE namespace: URI: urn:ietf:params:xml:ns:indea-1.0 URI: urn:ietf:params:xml:ns:indeReport-1.0 Wu, et al. Expires December 20, 2022 [Page 39] Internet-Draft IIIN-Data-Escrow December 2022 URI: urn:ietf:params:xml:ns:indeNotification-1.0 URI: urn:ietf:params:xml:ns:indeRReport-1.0 URI: urn:ietf:params:xml:ns:indeReports-1.0 URI: urn:ietf:params:xml:ns:indeNotifications-1.0 Registrant Contact: See the "Author's Address" section of this document. XML: None. Namespace URIs do not represent an XML specification. Registration request for the INDE XML schema: URI: urn:ietf:params:xml:schema:indea-1.0 URI: urn:ietf:params:xml:schema:indeReport-1.0 URI: urn:ietf:params:xml:schema:indeNotification-1.0 URI: urn:ietf:params:xml:schema:indeRReport-1.0 URI: urn:ietf:params:xml:schema:indeReports-1.0 URI: urn:ietf:params:xml:schema:indeNotifications-1.0 Registrant Contact: See the "Author's Address" section of this document. XML: See the "Formal Syntax" section of this document. 12. Privacy Considerations This specification defines a format that may be used to escrow personal data. The process of data escrow is governed by a legal document agreed by the parties, and such legal document must regulate the particularities regarding the protection of personal data. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, Wu, et al. Expires December 20, 2022 [Page 40] Internet-Draft IIIN-Data-Escrow December 2022 March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [I-D.draft-second-level-node-objects-mapping] HongJie Wu, Jian Chen, XiaoTian Fan, Meilan Chen, ZhiPing Li "Second-level Node (SLN) Data Objects Mapping", draft-second-level-node-objects-mapping-00 (work in progress). [I-D.draft-industrial-internet-identifier-data-escrow] HongJie Wu, Jian Chen, XiaoTian Fan, Meilan Chen, ZhiPing Li "Second-level Node (SLN) Data Objects Mapping", draft-industrial-internet-identifier-data- escrow-00 (work in progress). 14. Acknowledgments This document reference draft [draft-ietf-regext-data-escrow-03], thus, would like to thank the draft author G. Lozano. And would like to thank X. Fan, J. Chen, C. Ma, M. Chen, Z. Li who provided special important suggestions and invaluable comments. This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Hongjie Wu CAICT No.52 Huayuan North Road, Haidian District Beijing, Beijing, 100191 China Phone: +86 186 0106 5934 Email: wuhongjie@caict.ac.cn Wu, et al. Expires December 20, 2022 [Page 41] Internet-Draft IIIN-Data-Escrow December 2022 Jian Chen CAICT No.52 Huayuan North Road, Haidian District Beijing, Beijing, 100191 China Phone: +86 138 1103 3332 Email: chenjian3@caict.ac.cn Xiaotian Fan CAICT No.52 Huayuan North Road, Haidian District Beijing, Beijing, 100191 China Phone: +86 134 0108 6945 Email: fanxiaotian@caict.ac.cn Zhiping Li CAICT No.52 Huayuan North Road, Haidian District Beijing, Beijing, 100191 China Phone: +86 185 1107 1386 Email: lizhiping@caict.ac.cn Jiagui Xie CAICT No.52 Huayuan North Road, Haidian District Beijing, Beijing, 100191 China Phone: +86 150 0138 5070 Email: xiejiagui@caict.ac.cn Wu, et al. Expires December 20, 2022 [Page 42]