[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Internet Engineering Task Force                               H. Wu
Internet Draft                                                J. Chen
Intended status: Experimental                                 X. Fan
Expires: March 14 2021                                     Z. Li
 China Academy of Information and Communications Technology   J. Xie
                                                   September 14, 2020
               Industrial Internet Identifier Data Escrow Interface
                        draft-wu-identifier-data-escrow-interface-01


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 March 14, 2021.

Copyright Notice

   Copyright (c) 2020 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



Wu, et al.              Expires March  14, 2020                [Page 1]


Internet-Draft             IIIN-Data-Escrow              February 2020


   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. <indea:result> Object................................... 8
      4.2. <indeReport:report> Object.............................. 8
      4.3. <indeNotification:notification> Element................ 10
      4.4. <indeRReport:summary> Object........................... 11
      4.5. <indeReports:reports> Object........................... 13
      4.6. <indeNotifications:notifications> 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 March  14, 2020                [Page 2]


Internet-Draft             IIIN-Data-Escrow              February 2020


   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 March  14, 2020                [Page 3]


Internet-Draft             IIIN-Data-Escrow              February 2020


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 March  14, 2020                [Page 4]


Internet-Draft             IIIN-Data-Escrow              February 2020


   {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 March  14, 2020                [Page 5]


Internet-Draft             IIIN-Data-Escrow              February 2020


      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 March  14, 2020                [Page 6]


Internet-Draft             IIIN-Data-Escrow              February 2020


   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 March  14, 2020                [Page 7]


Internet-Draft             IIIN-Data-Escrow              February 2020


4. Object Description

   This section describes the base objects supported by this
   specification:

4.1. <indea:result> Object

   The TLN interfaces for SLN and data escrow agents <indea:result>
   object is used to provide information on the result of a
   verification process when interacting with the interfaces. The
   <indea:result> 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 <msg> element containing a human-readable description of the
      result code.

   o An OPTIONAL <description> element that includes additional details
      on the result conditions.

   An example of a <indea:result> object is presented below:

   <indea:result code="2001">

      <msg>The structure of the report is invalid.</msg>

     <description> 'XXX' could not be parsed as a number

     </description>

   </indea:result>

4.2. <indeReport:report> Object

   The contents of a data escrow deposit are described using a
   <indeReport:report> object. The <indeReport:report> object contains
   the following child elements:






Wu, et al.             Expires March  14, 2020                [Page 8]


Internet-Draft             IIIN-Data-Escrow              February 2020


   o An <id> element that contains the identifier assigned to this
      report. The report identifier MUST be the same as the "id"
      attribute from the <deposit>. 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 <id> element.

   o A <version> element contains the version of the specification
      used. This value MUST be 1.

   o A <indeSpecEscrow> 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 <indeSpecMapping> 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
      <indeSpecMapping> element MUST be included if the deposit was
      created using any version of the INRD objects mapping
      specification.

   o A <resend> element contains the value of the "resend" attribute
      of the <deposit>.

   o A <crDate> element contains the date and time that the deposit
      was created by the SLN.

   o A <kind> element is used to identify the kind of deposit: FULL,
      or DIFF (Differential).

   o A <watermark> element contains the date and time corresponding to
      the Timeline Watermark (<watermark> element) of the <deposit>.

   o A <indeHeader:header> element contains the header of the
      <deposit> as defined in [draft-second-level-node-objects-
      mapping].

   An example of a <indeReport:report> object is available in Section
   5.1.






Wu, et al.             Expires March  14, 2020                [Page 9]


Internet-Draft             IIIN-Data-Escrow              February 2020


4.3. <indeNotification:notification> Element

   The <indeNotification:notification> object is used by Data Escrow
   Agents to document the result of the data escrow deposit
   verification process. The <indeNotification:notification> object
   contains the following child elements:

   o A <deaName> element contains the name of the Data Escrow Agent.

   o A <version> element contains the version of the specification
      used. This value MUST be 1.

   o A <repDate> element contains the reported date. In case of a DVPN
      or DVFN notification this value MUST be the date of the
      <watermark> element of the <deposit>. In case of a DRFN deposit
      notification, this value MUST be the date for which no deposit
      was received from SLN.

   o A <status> element is used to specify the status of <repDate>.
      The possible values of status are: DVPN, DVFN and DRFN. The value
      for the <status> 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 <results> element contains the errors detected during
      the data escrow deposit verification process performed by the
      Data Escrow Agent. The <results> element includes one or more
      <indeReport:result> elements as defined in Section 4.1. In case
      of a DRFN or DVPN deposit notification the <results> element MUST
      NOT be present.

   o An OPTIONAL <reDate> 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 March  14, 2020               [Page 10]


Internet-Draft             IIIN-Data-Escrow              February 2020


   o An OPTIONAL <vaDate> 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 <lastFullDate> element contains the date of the
      Timeline Watermark (<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 <indeReport:report> 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
      <indeHeader:header> element MUST be generated by the Data Escrow
      Agent for the Timeline Watermark (<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 <indeHeader:header> element.

   o Note: In case of a DVPN or DVFN deposit notification, the <id> is
      used as unique identifier.

   An example of a <indeNotification:notification> object is available
   in Section 5.2.

4.4. <indeRReport:summary> Object

   Interfaces that support monitoring the reporting status for a
   specific repository, provide a <indeRReport:summary> 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 <indeRReport:summary>
   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 <crDate> element with the date and time in which the queried
      repository was created in the system.





Wu, et al.             Expires March  14, 2020               [Page 11]


Internet-Draft             IIIN-Data-Escrow              February 2020


   o A <depositSchedule> OPTIONAL element indicating the current Data
      Escrow Deposit schedule for the queried repository. Possible
      values are "None", "Weekly", and "Daily".

   o An OPTIONAL <lastFullDate> element indicating the date of the
      Timeline Watermark (<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 <statusReports> element with a <statusReport> element for each
      report type for the queried repository. Each <statusReport>
      element includes the following child elements:

         <type> : a string value indicating the report type to which the
         information provided pertains.

         <enabled> : a Boolean value indicating if the report type is
         enabled for the repository.

         <status> : 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 <issues> element included only when the <status>
         element has a value of "unsatisfactory", and includes an empty
         <issue> element for each date with a reporting problem found in
         the corresponding report type.  Each <issue> 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 March  14, 2020               [Page 12]


Internet-Draft             IIIN-Data-Escrow              February 2020


            "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 <timestamp> element to indicate the date and time in which the
      reporting status response was created.

4.5. <indeReports:reports> Object

   Interfaces that support monitoring and retrieving Data Escrow
   Reports received, provide a <indeReports:reports> object in the HTTP
   Entity-body when a HTTP/200 code is sent by the interface.

   The <indeReports:reports> element includes a list of
   <indeReports:receivedReport> objects, one for each
   <indeReport:report> successfully received by TLN. Each
   <indeReports:receivedReport> object includes the following child
   elements:

   o A <received> element to indicate the date and time in which the
      report was received by TLN.

   o A <indeReport:report> element as defined in Section 4.2.

4.6. <indeNotifications:notifications> Object

   Interfaces that support monitoring and retrieving Data Escrow
   Notifications received from Data Escrow Agents, provide a
   <indeNotifications:notifications> object in the HTTP Entity-body
   when a HTTP/200 code is sent by the interface.

   The <indeNotifications:notifications> element includes a list of
   <indeNotifications:receivedNotification> objects, one for each
   <indeNotification:notification> successfully received by TLN. Each
   <indeNotifications:receivedNotification> object includes the
   following child elements:

   o A <received> element to indicate the date and time in which the
      notification was received by TLN.

   o A <indeNotification:notification> element as defined in Section
      4.3.



Wu, et al.             Expires March  14, 2020               [Page 13]


Internet-Draft             IIIN-Data-Escrow              February 2020


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 <indeReport:report> 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/<prefix>/<id>

   where:

   o <prefix> MUST be substituted by the SLN Prefix for which the
      report is being provided.

   o <id> MUST be substituted by the identifier assigned to this
      report, which MUST be the same as the "id" attribute from the
      <deposit>.

   Note: the interface supports overwriting the information of a
   particular report <id> to support asynchronous interfaces between
   SLN and Data Escrow Agents.

   Example of a <indeReport:report> object for a data escrow deposit
   corresponding to a SLN Prefix repository:

   <?xml version="1.0" encoding="UTF-8"?>

      <indeReport:report

        xmlns:indeReport="urn:ietf:params:xml:ns:indeReport-1.0"

        xmlns:indeHeader="urn:ietf:params:xml:ns:indeHeader-1.0">

        <indeReport:id>2020117001</indeReport:id>

        <indeReport:version>1</indeReport:version>

        <indeReport:indeSpecEscrow>

          draft-industrial-internet-identifier-data-escrow-00

        </indeReport:indeSpecEscrow>


Wu, et al.             Expires March  14, 2020               [Page 14]


Internet-Draft             IIIN-Data-Escrow              February 2020


        <indeReport:indeSpecMapping>

          draft-second-level-node-objects-mapping-00

        </indeReport:indeSpecMapping>

        <indeReport:resend>0</indeReport:resend>

        <indeReport:crDate>2020-01-17T00:15:00.0Z</indeReport:crDate>

        <indeReport:kind>FULL</indeReport:kind>

        <indeReport:watermark>2020-01-17T00:00:00Z

        </indeReport:watermark>

        <indeHeader:header>

          <indeHeader:prefix>86.100</indeHeader:prefix>

          <indeHeader:count uri="urn:ietf:params:xml:ns:indeNode-1.0">2

          </indeHeader:count>

        </indeHeader:header>

     </indeReport:report>

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 <indeNotification:notification> 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/<prefix>

Where:

   o <prefix> MUST be substituted by the SLN Prefix for which the
      notification is being provided.



Wu, et al.             Expires March  14, 2020               [Page 15]


Internet-Draft             IIIN-Data-Escrow              February 2020


   If by 23:59:59 UTC, a deposit has not been successfully processed
   regardless of the final status of the verification process, a
   <indeNotification:notification> object with DRFN status MUST be send
   to TLN and SLN.

   Example of a <indeNotification:notification> object of a Data Escrow
   Agent notification:

   <?xml version="1.0" encoding="UTF-8"?>

     <indeNotification:notification

      xmlns:indeReport="urn:ietf:params:xml:ns:indeReport-1.0"

      xmlns:indeHeader="urn:ietf:params:xml:ns:indeHeader-1.0">

      <indeNotification:deaName>CAICT Data Escrow Agent.

       </indeNotification:deaName>

      <indeNotification:version>1</indeNotification:version>

      <indeNotification:repDate>2020-01-17</indeNotification:repDate>

      <indeNotification:status>DVPN</indeNotification:status>

      <indeNotification:reDate>2020-01-17T00:15:00.0Z

      </indeNotification:reDate>

      <indeNotification:vaDate>2020-01-17T05:15:00.0Z

      </indeNotification:vaDate>

      <indeNotification:lastFullDate>2020-01-10

      </indeNotification:lastFullDate>

      <indeReport:report>

        <indeReport:id>20200117001</indeReport:id>

        <indeReport:version>1</indeReport:version>

        <indeReport:indeSpecEscrow>

         draft-industrial-internet-identifier-data-escrow-00


Wu, et al.             Expires March  14, 2020               [Page 16]


Internet-Draft             IIIN-Data-Escrow              February 2020


        </indeReport:indeSpecEscrow>

        <indeReport:indeSpecMapping>

          draft-second-level-node-objects-mapping-00

        </indeReport:indeSpecMapping>

        <indeReport:resend>0</indeReport:resend>

        <indeReport:crDate>2020-01-17T00:15:00.0Z</indeReport:crDate>

        <indeReport:kind>FULL</indeReport:kind>

        <indeReport:watermark>2020-01-17T00:00:00Z

        </indeReport:watermark>

        <indeHeader:header>

         <indeHeader:prefix>86.100</indeHeader:prefix>

         <indeHeader:count uri="urn:ietf:params:xml:ns:indeNode-1.0">1

        </indeHeader:count>

        </indeHeader:header>

      </indeReport:report>

     </indeNotification:notification>

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 <response> object with a result element
   in the same HTTP transaction.

   The following HTTP status codes are standard across all interfaces:


Wu, et al.             Expires March  14, 2020               [Page 17]


Internet-Draft             IIIN-Data-Escrow              February 2020


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

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

   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 March  14, 2020               [Page 18]


Internet-Draft             IIIN-Data-Escrow              February 2020


    Content-Type: text/xml

   Content-Length: 246

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

   <response xmlns="urn:ietf:params:xml:ns:indea-1.0">

     <result code="1000">

       <msg>

       No ERRORs were found and the report has been accepted by TLN.

       </msg>

       <description></description>

     </result>

   </response>

   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

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

   <response xmlns="urn:ietf:params:xml:ns:indea-1.0">

    <result code="2001">

      <msg>The structure of the report is invalid.</msg>

      <description>

      'XX' could not be parsed as a number (line: 2 column:3)

      </description>

     </result>



Wu, et al.             Expires March  14, 2020               [Page 19]


Internet-Draft             IIIN-Data-Escrow              February 2020


   </response>

   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 <crDate> and
                <watermark> date should not be in the future.

    2003        Version is not supported.

    2004        The <id> in the <report> element and the <id> in the
                URL path do not match.

    2005        Interface is disabled for this SLN Prefix.

    2006        The <crDate> and <watermark> date should not be before
                the creation date of the prefix in the system.

    2201        The <prefix> in the <header> and the SLN Prefix in the
                URL path do not match.

    2202        Report regarding a differential deposit received for a
                Sunday (<watermark>).

    2203        Missing required <prefix> element in the <header>.

    2204        Multiple count elements with the same "uri" attribute
                values provided in the <header>.



6.1.2. Data Escrow Agent Reporting

   The following table lists the result codes of the interface:




Wu, et al.             Expires March  14, 2020               [Page 20]


Internet-Draft             IIIN-Data-Escrow              February 2020


    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 <crDate>,
                <watermark> and <repDate> date should not be in the
                future.

    2003        Version is not supported.

    2004        A DVPN notification exists for that date (<repDate>).

    2005        Interface is disabled for this SLN Prefix.

    2006        The <crDate>, <watermark> and <repDate> date should
                not be before the creation date of the SLN Prefix in
                the system.

    2007        The <repDate> and <watermark> in the notification do
                not match.

    2201        The <prefix> in the <header> and the SLN Prefix in the
                URL path do not match.

    2202        Notification regarding a differential deposit received
                for a Sunday (<repDate>).

    2203        Missing required <prefix> element in the <header>.

    2204        Multiple count elements with the same "uri" attribute
                values provided in the <header>.

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

    2207        A DVPN or DVFN was received, but the <report> element
                is missing in the notification.





Wu, et al.             Expires March  14, 2020               [Page 21]


Internet-Draft             IIIN-Data-Escrow              February 2020


    2208        A DRFN was received, but a <report> 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/<prefix>

   where:

   o <prefix> 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/<prefix>/<date>

   where:

   o <prefix> MUST be substituted by the SLN Prefix being queried.

   o <date> MUST be substituted by the day being queried. For example:
      2020-01-07




Wu, et al.             Expires March  14, 2020               [Page 22]


Internet-Draft             IIIN-Data-Escrow              February 2020


   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/<prefix>/<date>

   where:

   o <prefix> MUST be substituted by the SLN Prefix being queried.

   o <date> 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 March  14, 2020               [Page 23]


Internet-Draft             IIIN-Data-Escrow              February 2020


   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

   <?xml version="1.0" encoding="UTF-8"?>

      <schema targetNamespace="urn:ietf:params:xml:ns:indea-1.0"

        xmlns:indea="urn:ietf:params:xml:ns:indea-1.0"

        xmlns="http://www.w3.org/2001/XMLSchema"

        elementFormDefault="qualified">

        <annotation>

          <documentation>

            TLN interfaces for SLNs and data escrow agents


Wu, et al.             Expires March  14, 2020               [Page 24]


Internet-Draft             IIIN-Data-Escrow              February 2020


          </documentation>

        </annotation>

        <element name="response" type="indea:responseType"/>

        <element name="result" type="indea:resultType"/>

        <complexType name="responseType">

          <sequence>

            <element ref="indea:result" />

          </sequence>

        </complexType>

        <complexType name="resultType">

          <sequence>

            <element name="msg" type="token"/>

            <element name="description" type="string"

             minOccurs="0"/>

          </sequence>

          <attribute name="code" type="indea:codeType"

           use="required"/>

          <attribute name="count" type="unsignedInt"/>

        </complexType>

        <simpleType name="codeType">

          <restriction base="unsignedShort">

            <minInclusive value="1000"/>

            <maxInclusive value="9999"/>

          </restriction>


Wu, et al.             Expires March  14, 2020               [Page 25]


Internet-Draft             IIIN-Data-Escrow              February 2020


        </simpleType>

      </schema>

     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

   <?xml version="1.0" encoding="UTF-8"?>

      <schema targetNamespace="urn:ietf:params:xml:ns:indeReport-1.0"



Wu, et al.             Expires March  14, 2020               [Page 26]


Internet-Draft             IIIN-Data-Escrow              February 2020


        xmlns:indeReport="urn:ietf:params:xml:ns:indeReport-1.0"

        xmlns:indeHeader="urn:ietf:params:xml:ns:indeHeader-1.0"

        xmlns:inde="urn:ietf:params:xml:ns:inde-1.0"

        xmlns="http://www.w3.org/2001/XMLSchema"

        elementFormDefault="qualified">

        <import namespace="urn:ietf:params:xml:ns:indeHeader-1.0"/>

        <import namespace="urn:ietf:params:xml:ns:inde-1.0"/>

        <annotation>

          <documentation>

            Data Escrow Report schema

          </documentation>

        </annotation>

        <element name="report" type="indeReport:reportType"/>

        <complexType name="reportType">

          <sequence>

            <element name="id" type="inde:depositIdType"/>

            <element name="version" type="unsignedShort"/>

            <element name="indeSpecEscrow" type="token"/>

            <element name="indeSpecMapping" type="token" minOccurs="0"/>

            <element name="resend" type="unsignedShort"/>

            <element name="crDate" type="dateTime"/>

            <element name="kind" type="inde:depositTypeType"/>

            <element name="watermark" type="dateTime"/>

            <element ref="indeHeader:header"/>


Wu, et al.             Expires March  14, 2020               [Page 27]


Internet-Draft             IIIN-Data-Escrow              February 2020


          </sequence>

        </complexType>

      </schema>

   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

      <?xml version="1.0" encoding="UTF-8"?>



Wu, et al.             Expires March  14, 2020               [Page 28]


Internet-Draft             IIIN-Data-Escrow              February 2020


      <schema targetNamespace="urn:ietf:params:xml:ns:indeNotification-
     1.0"

        xmlns:indeNotifaction="urn:ietf:params:xml:ns:indeNotification-
        1.0"

        xmlns:indeReport="urn:ietf:params:xml:ns:indeReport-1.0"

        xmlns:indea="urn:ietf:params:xml:ns:indea-1.0"

        xmlns="http://www.w3.org/2001/XMLSchema"

        elementFormDefault="qualified">

        <import namespace="urn:ietf:params:xml:ns:indeReport-1.0"/>

        <import namespace="urn:ietf:params:xml:ns:indea-1.0"/>

        <annotation>

         <documentation> Data Escrow Notification schema

         </documentation>

        </annotation>

        <element name="notification"

        type="indeNotification:notificationType"/>

        <complexType name="notificationType">

          <sequence>

            <element name="deaName" type="indeNotification:nameType"/>

            <element name="version" type="unsignedShort"/>

            <element name="repDate" type="date"/>

            <element name="status" type="indeNotification:statusType"/>

            <element name="results" type="indeNotification:resultsType"

              minOccurs="0" />

            <element name="reDate" type="dateTime" minOccurs="0"/>


Wu, et al.             Expires March  14, 2020               [Page 29]


Internet-Draft             IIIN-Data-Escrow              February 2020


            <element name="vaDate" type="dateTime" minOccurs="0"/>

            <element name="lastFullDate" type="date" minOccurs="0"/>

            <element ref="indeReport:report" minOccurs="0"/>

          </sequence>

        </complexType>

        <simpleType name="nameType">

          <restriction base="normalizedString">

            <minLength value="1" />

            <maxLength value="255" />

          </restriction>

        </simpleType>

        <complexType name="resultsType">

          <sequence>

            <element ref="indea:result" maxOccurs="unbounded" />

          </sequence>

        </complexType>

        <simpleType name="statusType">

          <restriction base="token">

            <enumeration value="DVPN"/>

            <enumeration value="DVFN"/>

            <enumeration value="DRFN"/>

          </restriction>

        </simpleType>

      </schema>


Wu, et al.             Expires March  14, 2020               [Page 30]


Internet-Draft             IIIN-Data-Escrow              February 2020


   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

      <?xml version="1.0" encoding="UTF-8"?>

      <schema targetNamespace="urn:ietf:params:xml:ns:indeRReporting-
     1.0"

        xmlns:indeRReporting="urn:ietf:params:xml:ns:indeRReporting-
        1.0"



Wu, et al.             Expires March  14, 2020               [Page 31]


Internet-Draft             IIIN-Data-Escrow              February 2020


        xmlns:indeHeader="urn:ietf:params:xml:ns:indeHeader-1.0"

        xmlns="http://www.w3.org/2001/XMLSchema"

        elementFormDefault="qualified">

        <import namespace="urn:ietf:params:xml:ns:indeHeader-1.0" />

        <element name="summary" type="indeRReporting:summaryType"/>

        <complexType name="summaryType">

          <sequence>

            <group ref="indeHeader:repositoryTypeGroup"/>

            <element name="creationDate" type="dateTime" />

            <element name="depositSchedule"

               type="indeRReporting:depositScheduleType" />

            <element name="lastFullDate" type="date" minOccurs="0"/>

            <element name="statusReports"

               type="indeRReporting:statusReportsType" />

            <element name="timestamp" type="dateTime" />

          </sequence>

        </complexType>

        <simpleType name="depositScheduleType">

          <restriction base="token">

            <enumeration value="None" />

            <enumeration value="Weekly" />

            <enumeration value="Daily" />

          </restriction>

        </simpleType>


Wu, et al.             Expires March  14, 2020               [Page 32]


Internet-Draft             IIIN-Data-Escrow              February 2020


        <complexType name="statusReportsType">

          <sequence>

            <element name="statusReport"

            type="indeRReporting:statusReportType"
            maxOccurs="unbounded" />

          </sequence>

        </complexType>

        <complexType name="statusReportType">

          <sequence>

           <element name="type"
           type="indeRReporting:statusReportTypeType" />

           <element name="enabled" type="boolean" />

           <element name="status" type="indeRReporting:statusType" />

           <element name="issues" type="indeRReporting:issuesType"

             minOccurs="0" />

          </sequence>

        </complexType>

        <simpleType name="statusReportTypeType">

         <restriction base="token">

           <enumeration value="DEA_Notification" />

           <enumeration value="TLN_Notification" />

           <enumeration value="SLN_Escrow_Report" />

         </restriction>

        </simpleType>

        <simpleType name="statusType">


Wu, et al.             Expires March  14, 2020               [Page 33]


Internet-Draft             IIIN-Data-Escrow              February 2020


          <restriction base="token">

            <enumeration value="ok" />

            <enumeration value="unsatisfactory" />

          </restriction>

        </simpleType>

        <complexType name="issuesType">

          <sequence>

          <element name="issue" type="indeRReporting:issueType"
          maxOccurs="unbounded" />

          </sequence>

        </complexType>

        <complexType name="issueType">

          <attribute name="date" type="indeRReporting:issueDateType"
          use="required" />

          <attribute name="description"
          type="rriReporting:descriptionType" use="required" />

        </complexType>

        <simpleType name="issueDateType">

          <restriction base="token">

          <pattern

          value="\d{4}-(0[1-9]|1[012])(-(0[1-9]|[12][0-9]|3[01]))?" />

          </restriction>

        </simpleType>

        <simpleType name="descriptionType">

          <restriction base="token">



Wu, et al.             Expires March  14, 2020               [Page 34]


Internet-Draft             IIIN-Data-Escrow              February 2020


            <enumeration value="Missing_Deposit_Full" />

            <enumeration value="Missing_Deposit_Diff" />

            <enumeration value="Invalid_Deposit_Full" />

            <enumeration value="Invalid_Deposit_Diff" />

            <enumeration value="No_Report_Received" />

          </restriction>

        </simpleType>

      </schema>

   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 March  14, 2020               [Page 35]


Internet-Draft             IIIN-Data-Escrow              February 2020


   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

      <?xml version="1.0" encoding="UTF-8"?>

      <schema targetNamespace="urn:ietf:params:xml:ns:indeReports-1.0"

        xmlns:indeReport="urn:ietf:params:xml:ns:indeReport-1.0"

        xmlns:indeReports="urn:ietf:params:xml:ns:indeReports-1.0"

        xmlns="http://www.w3.org/2001/XMLSchema"

        elementFormDefault="qualified">

        <import namespace="urn:ietf:params:xml:ns:indeReport-1.0" />

        <element name="reports" type="indeReports:reportsType"/>

        <complexType name="reportsType">

          <sequence>

            <element name="receivedReport" maxOccurs="unbounded">

              <complexType>

                <sequence>

                  <element name="received" type="dateTime" />

                  <element ref="indeReport:report" />

                </sequence>

              </complexType>

            </element>

          </sequence>

        </complexType>


Wu, et al.             Expires March  14, 2020               [Page 36]


Internet-Draft             IIIN-Data-Escrow              February 2020


      </schema>

   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

     <?xml version="1.0" encoding="UTF-8"?>

     <schema targetNamespace="urn:ietf:params:xml:ns:indeNotifications-
     1.0"




Wu, et al.             Expires March  14, 2020               [Page 37]


Internet-Draft             IIIN-Data-Escrow              February 2020


     xmlns:indeNotifications="urn:ietf:params:xml:ns:indeNotifications-
    1.0"

     xmlns:indeNotification="urn:ietf:params:xml:ns:indeNotification-
    1.0"

      xmlns="http://www.w3.org/2001/XMLSchema"

       elementFormDefault="qualified">

      <import namespace="urn:ietf:params:xml:ns:ideNotification-1.0"/>

        <element name="notifications"

          type="indeNotifications:notificationsType"/>

        <complexType name="notificationsType">

          <sequence>

            <element name="receivedNotification" maxOccurs="unbounded">

              <complexType>

                <sequence>

                  <element name="received" type="dateTime" />

                  <element ref="indeNotification:notification" />

                </sequence>

              </complexType>

            </element>

          </sequence>

        </complexType>

      </schema>

   END






Wu, et al.             Expires March  14, 2020               [Page 38]


Internet-Draft             IIIN-Data-Escrow              February 2020


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 <?xml?> 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 March  14, 2020               [Page 39]


Internet-Draft             IIIN-Data-Escrow              February 2020


       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 March  14, 2020               [Page 40]


Internet-Draft             IIIN-Data-Escrow              February 2020


             March 1997, <https://www.rfc-editor.org/info/rfc2119>.
    [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
              <https://www.rfc-editor.org/info/rfc3339>.
   [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
             Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
             May 2017, <https://www.rfc-editor.org/info/rfc8174>.
   [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.
   [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 March  14, 2020               [Page 41]


Internet-Draft             IIIN-Data-Escrow              February 2020


   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 March  14, 2020               [Page 42]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/