Internet DRAFT - draft-wu-identifier-data-escrow-interface
draft-wu-identifier-data-escrow-interface
Internet Engineering Task Force H. Wu
Internet Draft J. Chen
Intended status: Experimental X. Fan
Expires: June 21 2023 Z. Li
China Academy of Information and Communications Technology J. Xie
December 16, 2022
Industrial Internet Identifier Data Escrow Interface
draft-wu-identifier-data-escrow-interface-06
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 June 21, 2023.
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
<Wu, etal.> Expires June 20, 2023 [Page 1]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 2]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 3]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 4]
Internet-Draft IIIN-Data-Escrow June 2023
{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 June 20, 2023 [Page 5]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 6]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 7]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 8]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 9]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 10]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 11]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 12]
Internet-Draft IIIN-Data-Escrow June 2023
"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 June 20, 2023 [Page 13]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 14]
Internet-Draft IIIN-Data-Escrow June 2023
<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 June 20, 2023 [Page 15]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 16]
Internet-Draft IIIN-Data-Escrow June 2023
</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 June 20, 2023 [Page 17]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 18]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 19]
Internet-Draft IIIN-Data-Escrow June 2023
</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 June 20, 2023 [Page 20]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 21]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 22]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 23]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 24]
Internet-Draft IIIN-Data-Escrow June 2023
</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 June 20, 2023 [Page 25]
Internet-Draft IIIN-Data-Escrow June 2023
</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 June 20, 2023 [Page 26]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 27]
Internet-Draft IIIN-Data-Escrow June 2023
</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 June 20, 2023 [Page 28]
Internet-Draft IIIN-Data-Escrow June 2023
<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 June 20, 2023 [Page 29]
Internet-Draft IIIN-Data-Escrow June 2023
<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 June 20, 2023 [Page 30]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 31]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 32]
Internet-Draft IIIN-Data-Escrow June 2023
<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 June 20, 2023 [Page 33]
Internet-Draft IIIN-Data-Escrow June 2023
<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 June 20, 2023 [Page 34]
Internet-Draft IIIN-Data-Escrow June 2023
<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 June 20, 2023 [Page 35]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 36]
Internet-Draft IIIN-Data-Escrow June 2023
</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 June 20, 2023 [Page 37]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 38]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 39]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 40]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 41]
Internet-Draft IIIN-Data-Escrow June 2023
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 June 20, 2023 [Page 42]
