idnits 2.17.1 draft-wu-identifier-data-escrow-interface-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 21, 2021) is 1041 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: '1-9' is mentioned on line 1573, but not defined -- Looks like a reference, but probably isn't: '012' on line 1573 -- Looks like a reference, but probably isn't: '12' on line 1573 == Missing Reference: '0-9' is mentioned on line 1573, but not defined -- Looks like a reference, but probably isn't: '01' on line 1573 == Unused Reference: 'I-D.draft-second-level-node-objects-mapping' is defined on line 1868, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-industrial-internet-identifier-data-escrow' is defined on line 1873, but no explicit reference was found in the text -- No information found for draft-second-level-node-objects-mapping - is the name correct? == Outdated reference: A later version (-06) exists of draft-industrial-internet-identifier-data-escrow-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force H. Wu 2 Internet Draft J. Chen 3 Intended status: Experimental X. Fan 4 Expires: December 21 2021 Z. Li 5 China Academy of Information and Communications Technology J. Xie 6 June 21, 2021 7 Industrial Internet Identifier Data Escrow Interface 8 draft-wu-identifier-data-escrow-interface-03 10 Abstract 12 This document describes the Data Escrow report requirement and 13 technical details of the interfaces provides by the Top-level Node 14 (TLN) to its contracted parties. Second-level Node (SLN) MUST 15 periodically send data escrow report to Top-level Node (TLN) and 16 Data Escrow Agent (DEA). DEA MUST sends report verify result to TLN 17 and SLN after processing the report. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on December 21, 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described in 54 Section 4.e of the Trust Legal Provisions and are provided without 55 warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction ................................................ 3 60 2. Conventions ................................................. 3 61 3. Data Escrow Requirement...................................... 4 62 3.1. Deposits ............................................... 4 63 3.2. Escrow Format .......................................... 4 64 3.3. Schedule for Deposits................................... 4 65 3.4. File Naming Conventions................................. 4 66 3.5. Processing of Deposits files............................ 5 67 3.6. Distribution of Public Keys............................. 6 68 3.7. Notification of Deposits................................ 6 69 3.8. Verification Procedure.................................. 7 70 3.9. Verification of Deposits................................ 7 71 4. Object Description .......................................... 8 72 4.1. Object................................... 8 73 4.2. Object.............................. 8 74 4.3. Element................ 10 75 4.4. Object........................... 11 76 4.5. Object........................... 13 77 4.6. Object............... 13 78 5. Interfaces for Data Escrow Reporting........................ 14 79 5.1. SLN Reporting ......................................... 14 80 5.2. Data Escrow Agent Reporting............................ 15 81 6. Technical details of the interfaces......................... 17 82 6.1. Response Object........................................ 18 83 6.1.1. SLN Reporting..................................... 20 84 6.1.2. Data Escrow Agent Reporting....................... 20 85 7. Monitoring the reporting status............................. 22 86 7.1. Monitoring the status of Repository Reports............ 22 87 7.2. Monitoring the status of Data Escrow Reports........... 22 88 7.3. Monitoring the status of Data Escrow Notifications......23 89 8. Formal Syntax .............................................. 23 90 8.1. Result Object ......................................... 23 91 8.2. Report Object ......................................... 26 92 8.3. Notification Object.................................... 28 93 8.4. Summary Object ........................................ 31 94 8.5. Reports Object ........................................ 35 95 8.6. Notifications Object................................... 37 97 9. Internationalization Considerations......................... 39 98 10. Security Considerations.................................... 39 99 11. IANA Considerations........................................ 39 100 12. Privacy Considerations..................................... 40 101 13. References ................................................ 40 102 13.1. Normative References.................................. 40 103 14. Acknowledgments ........................................... 41 105 1. Introduction 107 This document describes the Data Escrow report requirement and 108 technical details of the interfaces provides by the Top-level Node 109 (TLN) to its contracted parties. Second-level Node (SLN) MUST 110 periodically send data escrow report to Top-level Node (TLN) and 111 Data Escrow Agent (DEA). DEA MUST sends report verify result to TLN 112 and SLN after processing the report. 114 2. Conventions 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in 119 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 TOP-LEVEL NODE (TLN).In the context of this draft the definition will 123 indicate an organization providing Registry Services for a top level 124 identifier. TLN also provide Second-level Node manager services. 126 SECOND-LEVEL NODE (SLN). In the context of this draft the definition 127 will indicate an organization providing Registry Services for a 128 second level identifier. 130 Data Escrow Agent. The organization designated by the SLN to receive 131 and guard data escrow deposits from the SLN. 133 Date and Time. Numerous fields indicate "dates", such as the 134 creation and expiry dates for objects. These fields SHALL contain 135 timestamp indicating the date and time in UTC, specified in Internet 136 Date/Time Format (see [RFC3339], Section 5.6) with the time-offset 137 specified as "Z". 139 XML is case sensitive. Unless stated otherwise, XML specifications 140 and examples provided in this document MUST be interpreted in the 141 character case presented in order to develop a conforming 142 implementation. 144 3. Data Escrow Requirement 146 SLN MUST engage an independent entity to act as data escrow agent 147 for the provision of data escrow services. The following sections 148 define the data escrow requirement. 150 3.1. Deposits 152 There will be two types of Deposits: Full and Differential. 154 o Full Deposit will consist of data that reflects the state of the 155 SLN as of 00:00:00 UTC (Coordinated Universal Time) on the day 156 that such Full Deposit is submitted to Escrow Agent. 158 o Differential Deposit means data that reflects all transactions 159 that were not reflected in the last previous Full or Differential 160 Deposit, as the case may be. Each Differential Deposit will 161 contain all database transactions since the previous Deposit was 162 completed as of 00:00:00 UTC of each day. 164 3.2. Escrow Format 166 Deposit's Format. SLN will include identifier node elements 167 described in draft-industrial-internet-identifier-data-escrow 168 (IIIDE) and draft-second-level-node-objects-mapping (SLNOM) in the 169 Deposits. If IIIDE and SLNOM not already an RFC, SLN will use the 170 most recent draft version of the IIIDE and SLNOM available at the 171 Effective Date. Once the IIIDE and SLNOM is published as a RFC, SLN 172 will implement that version of the IIIDE and SLNOM Specification, no 173 later than one hundred eighty calendar days after. 175 3.3. Schedule for Deposits 177 SLN will submit a set of escrow files on a daily basis as follows: 179 o Each Sunday, a Full Deposit must be submitted to the Escrow Agent 180 by 23:59 UTC. 182 o The other six (6) days of the week, a Full Deposit or the 183 corresponding Differential Deposit must be submitted to Escrow 184 Agent by 23:59 UTC. 186 3.4. File Naming Conventions 188 Data Escrow Deposit Files will be named according to the following 189 convention: 191 {Snode}_{YYYY-MM-DD}_{type}_S{#}_R{rev}.{ext} 193 o {Snode} is replaced with the SLN prefix. 195 o {YYYY-MM-DD} is replaced by the date corresponding to the time 196 used as a timeline watermark for the transactions. 198 o {type} is replaced by: 200 "full", if the data represents a Full Deposit; 202 "diff", if the data represents a Differential Deposit; 204 o {#} is replaced by the position of the file in a series of files, 205 beginning with "1"; in case of a lone file, this must be replaced 206 by "1". If it is a report file, there is no S{#}. 208 o {rev} is replaced by the number of the revision(or resend) of the 209 file beginning with "0". 211 o {ext} replaced by the "inde", Replaced by the "sig" if it is a 212 digital signature file, replaced by the "rep" if it is a report 213 file. 215 3.5. Processing of Deposits files 217 The use of compression is recommended in order to reduce electronic 218 data transfer times, and storage capacity requirements. Data 219 encryption will be used to ensure the privacy of registry escrow 220 data. Files processed for compression and encryption will be in the 221 binary OpenPGP format as per OpenPGP Message Format. The process to 222 follow for the data file in original text format is: 224 1) Compress the data file(s). According to RFC 4880, the recommended 225 compression algorithm is zip. 227 2) A compressed and encrypted OpenPGP Message is created using the 228 tarball file as sole input. The suggested algorithm for 229 compression is ZIP as per RFC 4880. The compressed data will be 230 encrypted using the escrow agent's public key. The suggested 231 algorithms for Public-key encryption are Elgamal and RSA as per 232 RFC 4880. The suggested algorithms for Symmetric-key encryption 233 are TripleDES, AES128 and CAST5 as per RFC 4880. 235 3) The file may be split as necessary if, once compressed and 236 encrypted, it is larger than the file size limit agreed with the 237 escrow agent. Every part of a split file, or the whole file if not 238 split, will be called a processed file in this section. 240 4) A digital signature file will be generated for every processed 241 file using the SLN private key. The digital signature file will be 242 in binary OpenPGP format, and will not be compressed or encrypted. 243 The suggested algorithms for Digital signatures are DSA and RSA as 244 per RFC 4880. The suggested algorithm for Hashes in Digital 245 signatures is SHA256. 247 5) The processed files and digital signature files will then be 248 transferred to the Escrow Agent through secure electronic 249 mechanisms, such as, SFTP, SCP, HTTPS file upload, etc. 251 6) The Escrow Agent will then validate every (processed) transferred 252 data file using the procedure described in Section 3.8. 254 3.6. Distribution of Public Keys 256 Each of SLN and Escrow Agent will distribution this public key to 257 the other party via email to an email address to be specified. Each 258 party will confirm receipt of the other party's public key with a 259 reply email, and the distributing party will subsequently reconfirm 260 the authenticity of the key transmitted via offline methods, like in 261 person meeting, telephone, etc. In this way, public key transmission 262 is authenticated to a user able to send and receive mail via a mail 263 server operated by the distributing party. Escrow Agent, SLN and TLN 264 will exchange public keys by the same procedure. 266 3.7. Notification of Deposits 268 Along with the delivery of each Deposit, SLN will deliver to Data 269 Escrow Agent and TLN a written statement that includes a copy of the 270 report generated upon creation of the Deposit and states that the 271 Deposit has been inspected by SLN and is complete and accurate. The 272 preparation and submission of this statement must be performed by 273 the SLN or its designee, provided that such designee may not be the 274 Escrow Agent or any of Escrow Agent's Affiliates. SLN will include 275 the Deposit's "id" and "resend" attributes in its statement. The 276 attributes are explained in IIIDE and SLNOM. The written statement 277 file is submitted to the TLN by calling the data escrow interfaces 278 provided by TLN. The written statement file, data escrow file and 279 digital signature file are transmitted to DEA through security 280 electronic mechanisms (for example, SFTP, SCP, HTTPS file upload, 281 etc.). 283 The Data Escrow Agent receives the deposit and verifies it. Every 284 time it verifies a deposit, it must send the verification results to 285 SLN and TLN. The verification results file is submitted to the TLN 286 by calling the data escrow interfaces provided by TLN. The 287 verification results file transmitted to SLN by verified email. 289 When the SLN fails to send the deposit file within the time limit 290 specified in the deposit schedule, the Data Escrow Agent needs to 291 notify the SLN via verified email. 293 3.8. Verification Procedure 295 o The signature file of each processed file is validated. 297 o If processed files are pieces of a bigger file, the latter is put 298 together. 300 o Each file obtained in the previous step is then decrypted and 301 uncompressed. 303 o Each data file contained in the previous step is then validated 304 against the format. 306 o The data escrow agent extended verification process as well as 307 any other data escrow verification process contained in such 308 reference. 310 If any discrepancy is found in any of the steps, the Deposit will be 311 considered incomplete, and must complete this data escrow before the 312 next data escrow time specified 314 3.9. Verification of Deposits 316 o Within twenty-four hours after receiving each Deposit or 317 corrected Deposit, DEA must verify the format and completeness of 318 each Deposit and deliver to TLN and SLN a notification generated 319 for each Deposit. 321 o If DEA discovers that any Deposit fails the verification 322 procedures or if DEA does not receive any Scheduled Deposit, DEA 323 must notify SLN and TLN either by email, fax or phone. Upon 324 notification of such verification or delivery failure, SLN must 325 begin developing modifications, updates, corrections, and other 326 fixes of the Deposit necessary for the Deposit to be delivered 327 and pass the verification procedures and deliver such fixes to 328 DEA and TLN as promptly as possible. 330 4. Object Description 332 This section describes the base objects supported by this 333 specification: 335 4.1. Object 337 The TLN interfaces for SLN and data escrow agents 338 object is used to provide information on the result of a 339 verification process when interacting with the interfaces. The 340 object contains the following attribute and child 341 elements: 343 o A "code" attribute whose value is a four-digit decimal number 344 that identifies the result of a process. Available result code 345 values MUST be defined for the corresponding process. 347 o An OPTIONAL "count" attribute to indicate the number of industry 348 internet identifier node object related to the reported result. 350 o A element containing a human-readable description of the 351 result code. 353 o An OPTIONAL element that includes additional details 354 on the result conditions. 356 An example of a object is presented below: 358 360 The structure of the report is invalid. 362 'XXX' could not be parsed as a number 364 366 368 4.2. Object 370 The contents of a data escrow deposit are described using a 371 object. The object contains 372 the following child elements: 374 o An element that contains the identifier assigned to this 375 report. The report identifier MUST be the same as the "id" 376 attribute from the . If the data escrow deposit does not 377 include a unique identifier, the Data Escrow Agent MUST generate 378 a unique identifier to reference the data escrow deposit and use 379 it in the element. 381 o A element contains the version of the specification 382 used. This value MUST be 1. 384 o A element contains the version of the Data 385 Escrow Specification (e.g. draft-caict-industrial-internet- 386 identifier-data-escrow-00) used to create the deposit. After the 387 specification is published as an RFC, the value MUST be the RFC 388 number assigned by IANA. 390 o An OPTIONAL element contains the version of the 391 Identifier Node Registration Data (INRD) Objects Mapping (e.g. 392 draft-second-level-node-objects-mapping-00) used to create the 393 deposit. After the specification is published as an RFC, the 394 value MUST be the RFC number assigned by IANA. The 395 element MUST be included if the deposit was 396 created using any version of the INRD objects mapping 397 specification. 399 o A element contains the value of the "resend" attribute 400 of the . 402 o A element contains the date and time that the deposit 403 was created by the SLN. 405 o A element is used to identify the kind of deposit: FULL, 406 or DIFF (Differential). 408 o A element contains the date and time corresponding to 409 the Timeline Watermark ( element) of the . 411 o A element contains the header of the 412 as defined in [draft-second-level-node-objects- 413 mapping]. 415 An example of a object is available in Section 416 5.1. 418 4.3. Element 420 The object is used by Data Escrow 421 Agents to document the result of the data escrow deposit 422 verification process. The object 423 contains the following child elements: 425 o A element contains the name of the Data Escrow Agent. 427 o A element contains the version of the specification 428 used. This value MUST be 1. 430 o A element contains the reported date. In case of a DVPN 431 or DVFN notification this value MUST be the date of the 432 element of the . In case of a DRFN deposit 433 notification, this value MUST be the date for which no deposit 434 was received from SLN. 436 o A element is used to specify the status of . 437 The possible values of status are: DVPN, DVFN and DRFN. The value 438 for the element is determined by the three types of 439 notices:: 441 Deposit Receipt Failure Notice (DRFN): generated by the Data 442 Escrow Agent when no deposit is received pursuant to the data 443 escrow deposit schedule. 445 Deposit Verification Failure Notice (DVFN): generated by the 446 Data Escrow Agent when a deposit is received, but the final 447 result of the verification process is failure. 449 Deposit Verification Pass Notice (DVPN): generated by the Data 450 Escrow Agent when a deposit is received and the final result of 451 the verification process is success. 453 o An OPTIONAL element contains the errors detected during 454 the data escrow deposit verification process performed by the 455 Data Escrow Agent. The element includes one or more 456 elements as defined in Section 4.1. In case 457 of a DRFN or DVPN deposit notification the element MUST 458 NOT be present. 460 o An OPTIONAL element contains the date and time that the 461 deposit was successfully received by the Data Escrow Agent. In 462 case of a DRFN deposit notification this element MUST NOT be 463 present. 465 o An OPTIONAL element contains the date and time that the 466 deposit was processed for validation by the Data Escrow Agent. 467 In case of a DRFN deposit notification this element MUST NOT be 468 present. 470 o An OPTIONAL element contains the date of the 471 Timeline Watermark ( element) of the most recent FULL 472 deposit that was successfully validated by the Data Escrow Agent. 473 This element MUST NOT be present if a successfully validated full 474 deposit has never been deposited. 476 o An OPTIONAL element is used by the Data 477 Escrow Agent to provide extended information about the deposit. 478 In case of a DRFN deposit notification this element MUST NOT be 479 present. In case of a DVPN or DVFN deposit notification this 480 element MUST be present. When this element is present, the 481 element MUST be generated by the Data Escrow 482 Agent for the Timeline Watermark ( element) of the 483 deposit being processed. If the deposit being processed is a 484 differential deposit, the Data Escrow Agent MUST process the last 485 full plus all differentials escrow deposits from the same 486 repository to generate the element. 488 o Note: In case of a DVPN or DVFN deposit notification, the is 489 used as unique identifier. 491 An example of a object is available 492 in Section 5.2. 494 4.4. Object 496 Interfaces that support monitoring the reporting status for a 497 specific repository, provide a object as 498 defined by the schema in Section 6 in the HTTP Entity-body when a 499 HTTP/200 code is sent by the interface. The 500 element includes the following child elements: 502 o A choice of one of the elements as defined in the 503 "indeHeader:repositoryTypeGroup" (see [draft-second-level-node- 504 objects-mapping]) that indicates the unique identifier for the 505 repository being escrowed. 507 o A element with the date and time in which the queried 508 repository was created in the system. 510 o A OPTIONAL element indicating the current Data 511 Escrow Deposit schedule for the queried repository. Possible 512 values are "None", "Weekly", and "Daily". 514 o An OPTIONAL element indicating the date of the 515 Timeline Watermark ( element) of the most recent FULL 516 deposit that was successfully validated for the queried 517 repository as notified by the Data Escrow Agent. 519 o A element with a element for each 520 report type for the queried repository. Each 521 element includes the following child elements: 523 : a string value indicating the report type to which the 524 information provided pertains. 526 : a Boolean value indicating if the report type is 527 enabled for the repository. 529 : a string value indicating the reporting status. A 530 value of "ok" indicates there are no reporting issues in the 531 corresponding report type, otherwise the value of 532 "unsatisfactory" is shown. 534 An OPTIONAL element included only when the 535 element has a value of "unsatisfactory", and includes an empty 536 element for each date with a reporting problem found in 537 the corresponding report type. Each element includes a 538 REQUIRED "date" attribute in "YYYY-MM-DD" format and a REQUIRED 539 "description" attribute to describe the issue. The possible 540 values to describe each reporting issue are: 542 "Missing_Deposit_Full": If the latest notification received 543 from the Data Escrow Agent for the date indicates that a 544 scheduled "Full" deposit was not submitted by the repository 545 owner. 547 "Missing_Deposit_Diff": If the latest notification received 548 from the Data Escrow Agent for the date indicates that a 549 scheduled "Differential" deposit was not submitted by the 550 repository owner. 552 "Invalid_Deposit_Full": If the latest notification received 553 from the Data Escrow Agent for the date indicates that a 554 "Full" deposit was received by the Data Escrow Agent, but 555 failed the verification process. 557 "Invalid_Deposit_Diff": If the latest notification received 558 from the Data Escrow Agent for the date indicates that a 559 "Differential" deposit was received by the Data Escrow 560 Agent, but failed the verification process. 562 "No_Report_Received" If no report has been received for the 563 date. 565 o A element to indicate the date and time in which the 566 reporting status response was created. 568 4.5. Object 570 Interfaces that support monitoring and retrieving Data Escrow 571 Reports received, provide a object in the HTTP 572 Entity-body when a HTTP/200 code is sent by the interface. 574 The element includes a list of 575 objects, one for each 576 successfully received by TLN. Each 577 object includes the following child 578 elements: 580 o A element to indicate the date and time in which the 581 report was received by TLN. 583 o A element as defined in Section 4.2. 585 4.6. Object 587 Interfaces that support monitoring and retrieving Data Escrow 588 Notifications received from Data Escrow Agents, provide a 589 object in the HTTP Entity-body 590 when a HTTP/200 code is sent by the interface. 592 The element includes a list of 593 objects, one for each 594 successfully received by TLN. Each 595 object includes the 596 following child elements: 598 o A element to indicate the date and time in which the 599 notification was received by TLN. 601 o A element as defined in Section 602 4.3. 604 5. Interfaces for Data Escrow Reporting 606 This section describes the interfaces provided by TLN to SLN and 607 Data Escrow Agents in order to fulfill the reporting requirements. 609 5.1. SLN Reporting 611 In order to satisfy the Section 3.7 requirement, the SLN sends to 612 TLN and Data Escrow Agent a object as defined 613 Section 4.2 for each deposit successfully sent to the Data Escrow 614 Agent, using the PUT HTTP verb in the interface provided by TLN at: 616 https://inde-api.caict.ac.cn/report/sln-escrow-report// 618 where: 620 o MUST be substituted by the SLN Prefix for which the 621 report is being provided. 623 o MUST be substituted by the identifier assigned to this 624 report, which MUST be the same as the "id" attribute from the 625 . 627 Note: the interface supports overwriting the information of a 628 particular report to support asynchronous interfaces between 629 SLN and Data Escrow Agents. 631 Example of a object for a data escrow deposit 632 corresponding to a SLN Prefix repository: 634 636 642 2020117001 644 1 646 648 draft-industrial-internet-identifier-data-escrow-00 650 651 653 draft-second-level-node-objects-mapping-00 655 657 0 659 2020-01-17T00:15:00.0Z 661 FULL 663 2020-01-17T00:00:00Z 665 667 669 86.100 671 2 673 675 677 679 5.2. Data Escrow Agent Reporting 681 This Specification requires Data Escrow Agents to deliver TLN and SLN 682 with a notification object every time a successfully processed deposit 683 is received from the SLN regardless of the final status of the 684 verification process. 686 In order to satisfy this requirement, the Data Escrow Agent sends to 687 TLN and SLN a object as defined in 688 Section 4.3, using the POST HTTP verb in the interface provided by TLN 689 at: 691 https://inde-api.caict.ac.cn/report/escrow-agent-notification/ 693 Where: 695 o MUST be substituted by the SLN Prefix for which the 696 notification is being provided. 698 If by 23:59:59 UTC, a deposit has not been successfully processed 699 regardless of the final status of the verification process, a 700 object with DRFN status MUST be send 701 to TLN and SLN. 703 Example of a object of a Data Escrow 704 Agent notification: 706 708 714 CAICT Data Escrow Agent. 716 718 1 720 2020-01-17 722 DVPN 724 2020-01-17T00:15:00.0Z 726 728 2020-01-17T05:15:00.0Z 730 732 2020-01-10 734 736 738 20200117001 740 1 742 744 draft-industrial-internet-identifier-data-escrow-00 746 748 750 draft-second-level-node-objects-mapping-00 752 754 0 756 2020-01-17T00:15:00.0Z 758 FULL 760 2020-01-17T00:00:00Z 762 764 766 86.100 768 1 770 772 774 776 778 6. Technical details of the interfaces 780 Content-type value in the HTTP header: 782 The client MUST set "text/xml" in the HTTP header Content-type when 783 using the SLN Reporting and Data Escrow Agent Reporting interfaces. 785 The interfaces support HTTP streams only (HTTP multi-part forms are 786 not supported) 788 After successfully receiving an input in any of the interfaces, TLN 789 validates it and provides a object with a result element 790 in the same HTTP transaction. 792 The following HTTP status codes are standard across all interfaces: 794 o The interface provides a HTTP/200 status code and sets the HTTP 795 header Content-type: text/xml, if the interface was able to 796 receive the input successfully, the client MUST review the 797 response object to verify the result code after processing the 798 input. 800 o The interface provides a HTTP/400 status code and sets the HTTP 801 header Content-type: text/xml, if the input is incorrect or the 802 syntax of the input is invalid. A response object is included 803 with the input validation failure details. 805 o The interface provides a HTTP/401 status code and sets the HTTP 806 header Content-type: text/plain, if the credentials provided does 807 not authorize the SLN to upload a report for that . 809 o The interface provides a HTTP/403 status code and sets the HTTP 810 header Content-type: text/plain, if the credentials provided are 811 valid but are being used to access a resource that permission is 812 not granted for or the connecting IP address is not whitelisted 813 for the . 815 o The interface provides a HTTP/405 status code if the interface 816 does not support the request method. 818 o The interface provides a HTTP/500 status code and sets the HTTP 819 header Content-type: text/plain, if the system is experiencing a 820 general failure. The sending party is responsible to send the 821 input again. 823 o The interface provides a HTTP/501 status code and sets the HTTP 824 header Content-type: text/plain, if the functionality has not yet 825 been implemented. 827 After sending the response, the interfaces closes the TCP connection 829 6.1. Response Object 831 After processing the input provided in any of the interfaces, a 832 response object as defined in section 4.1 is provided in the HTTP 833 Entity-body when an HTTP/200 or HTTP/400 status code is sent by the 834 interface. 836 An example of a response object upon successful input receipt is 837 presented below: 839 HTTP/1.1 200 OK 840 Content-Type: text/xml 842 Content-Length: 246 844 846 848 850 852 No ERRORs were found and the report has been accepted by TLN. 854 856 858 860 862 An example of a response object in the event of input error is 863 presented below: 865 HTTP/1.1 400 Bad Request 867 Content-Type: text/xml 869 Content-Length: 279 871 873 875 877 The structure of the report is invalid. 879 881 'XX' could not be parsed as a number (line: 2 column:3) 883 885 887 889 The following sections provide the Result Codes per interface: 891 6.1.1. SLN Reporting 893 The following table lists the result codes of the interface: 895 Result Code Message 897 1000 No ERRORs were found and the report has been accepted 898 by TLN. 900 2001 The request did not validate against the schema. 902 2002 Report for a date in the future. The and 903 date should not be in the future. 905 2003 Version is not supported. 907 2004 The in the element and the in the 908 URL path do not match. 910 2005 Interface is disabled for this SLN Prefix. 912 2006 The and date should not be before 913 the creation date of the prefix in the system. 915 2201 The in the
and the SLN Prefix in the 916 URL path do not match. 918 2202 Report regarding a differential deposit received for a 919 Sunday (). 921 2203 Missing required element in the
. 923 2204 Multiple count elements with the same "uri" attribute 924 values provided in the
. 926 6.1.2. Data Escrow Agent Reporting 928 The following table lists the result codes of the interface: 930 Result Code Message 932 1000 No ERRORs were found and the notification has been 933 accepted by TLN. 935 2001 The request did not validate against the schema. 937 2002 Notification for a date in the future. The , 938 and date should not be in the 939 future. 941 2003 Version is not supported. 943 2004 A DVPN notification exists for that date (). 945 2005 Interface is disabled for this SLN Prefix. 947 2006 The , and date should 948 not be before the creation date of the SLN Prefix in 949 the system. 951 2007 The and in the notification do 952 not match. 954 2201 The in the
and the SLN Prefix in the 955 URL path do not match. 957 2202 Notification regarding a differential deposit received 958 for a Sunday (). 960 2203 Missing required element in the
. 962 2204 Multiple count elements with the same "uri" attribute 963 values provided in the
. 965 2205 The notification for the report "id" already exists. 967 2206 A Deposit Verification Pass Notice (DVPN) notification 968 was received, but the Domain Name count is missing in 969 the
. 971 2207 A DVPN or DVFN was received, but the element 972 is missing in the notification. 974 2208 A DRFN was received, but a element exists in 975 the notification. 977 7. Monitoring the reporting status 979 SLNs May monitor the status of the reports described in Chapter 3 980 using the following interfaces that supports the HEAD HTTP verb: 982 7.1. Monitoring the status of Repository Reports 984 SLNs May monitor the status of repository using the following 985 interface: 987 https://inde-api.caict.ac.cn/info/report/sln-escrow- 988 repository/ 990 where: 992 o MUST be substituted by the SLN Prefix being queried. 994 Possible results are: 996 o The interface provides a HTTP/200 status code, if syntactically 997 valid data escrow reports was received for the queried prefix. 999 o The interface provides a HTTP/404 status code, if syntactically 1000 valid data escrow reports has not been received for the queried 1001 prefix. 1003 7.2. Monitoring the status of Data Escrow Reports 1005 SLNs May monitor the status of Data Escrow Reports using the 1006 following interface: 1008 https://inde-api.caict.ac.cn/info/report/sln-escrow- 1009 report// 1011 where: 1013 o MUST be substituted by the SLN Prefix being queried. 1015 o MUST be substituted by the day being queried. For example: 1016 2020-01-07 1018 Possible results are: 1020 o The interface provides a HTTP/200 status code, if a syntactically 1021 valid data escrow report was received for the queried date. 1023 o The interface provides a HTTP/404 status code, if a syntactically 1024 valid data escrow report has not been received for the queried 1025 date. 1027 7.3. Monitoring the status of Data Escrow Notifications 1029 SLNs and Data Escrow Agents May monitor the status of Data Escrow 1030 Notifications using the following interface: 1032 https://inde-api.caict.ac.cn/info/report/escrow-agent- 1033 notification// 1035 where: 1037 o MUST be substituted by the SLN Prefix being queried. 1039 o MUST be substituted by the day being queried. For example: 1040 2020-01-07 1042 Possible results are: 1044 o The interface provides a HTTP/200 status code, if a syntactically 1045 valid data escrow notification was received for the queried date. 1047 o The interface provides a HTTP/404 status code, if a syntactically 1048 valid data escrow notification has not been received for the 1049 queried date. 1051 8. Formal Syntax 1053 The schema of the Result, Report, Notification, Summary, Reports, 1054 and Notifications objects described in Chapter 4 are presented here. 1056 The BEGIN and END tags are not part of the schema; they are used to 1057 note the beginning and ending of the schema for URI registration 1058 purposes. 1060 8.1. Result Object 1062 Copyright (c) 2019 IETF Trust and the persons identified as authors 1063 of the code. All rights reserved. 1065 Redistribution and use in source and binary forms, with or without 1066 modification, are permitted provided that the following conditions 1067 are met: 1069 o Redistributions of source code must retain the above copyright 1070 notice, this list of conditions and the following disclaimer. 1072 o Redistributions in binary form must reproduce the above copyright 1073 notice, this list of conditions and the following disclaimer in 1074 the documentation and/or other materials provided with the 1075 distribution. 1077 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1078 names of specific contributors, may be used to endorse or promote 1079 products derived from this software without specific prior 1080 written permission. 1082 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1083 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1084 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 1085 FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 1086 COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 1087 INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 1088 BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 1089 LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 1090 CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 1091 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN 1092 ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 1093 POSSIBILITY OF SUCH DAMAGE. 1095 BEGIN 1097 1099 1107 1109 1111 TLN interfaces for SLNs and data escrow agents 1113 1115 1117 1119 1121 1123 1125 1127 1129 1131 1133 1135 1137 1141 1143 1147 1149 1151 1153 1155 1157 1159 1161 1163 1165 END 1167 8.2. Report Object 1169 Copyright (c) 2019 IETF Trust and the persons identified as authors 1170 of the code. All rights reserved. 1172 Redistribution and use in source and binary forms, with or without 1173 modification, are permitted provided that the following conditions 1174 are met: 1176 o Redistributions of source code must retain the above copyright 1177 notice, this list of conditions and the following disclaimer. 1179 o Redistributions in binary form must reproduce the above copyright 1180 notice, this list of conditions and the following disclaimer in 1181 the documentation and/or other materials provided with the 1182 distribution. 1184 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1185 names of specific contributors, may be used to endorse or promote 1186 products derived from this software without specific prior 1187 written permission. 1189 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1190 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1191 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 1192 FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 1193 COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 1194 INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 1195 BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 1196 LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 1197 CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 1198 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN 1199 ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 1200 POSSIBILITY OF SUCH DAMAGE. 1202 BEGIN 1204 1206 1217 1219 1221 1223 1225 Data Escrow Report schema 1227 1229 1231 1233 1235 1237 1239 1241 1243 1245 1247 1249 1251 1253 1255 1257 1259 1261 END 1263 8.3. Notification Object 1265 Copyright (c) 2019 IETF Trust and the persons identified as authors 1266 of the code. All rights reserved. 1268 Redistribution and use in source and binary forms, with or without 1269 modification, are permitted provided that the following conditions 1270 are met: 1272 o Redistributions of source code must retain the above copyright 1273 notice, this list of conditions and the following disclaimer. 1275 o Redistributions in binary form must reproduce the above copyright 1276 notice, this list of conditions and the following disclaimer in 1277 the documentation and/or other materials provided with the 1278 distribution. 1280 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1281 names of specific contributors, may be used to endorse or promote 1282 products derived from this software without specific prior 1283 written permission. 1285 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1286 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1287 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 1288 FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 1289 COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 1290 INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 1291 BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 1292 LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 1293 CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 1294 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN 1295 ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 1296 POSSIBILITY OF SUCH DAMAGE. 1298 BEGIN 1300 1301 1315 1317 1319 1321 Data Escrow Notification schema 1323 1325 1327 1331 1333 1335 1337 1339 1341 1343 1347 1348 1350 1352 1354 1356 1358 1360 1362 1364 1366 1368 1370 1372 1374 1376 1378 1380 1382 1384 1386 1388 1390 1392 1394 1396 END 1398 8.4. Summary Object 1400 Copyright (c) 2019 IETF Trust and the persons identified as authors 1401 of the code. All rights reserved. 1403 Redistribution and use in source and binary forms, with or without 1404 modification, are permitted provided that the following conditions 1405 are met: 1407 o Redistributions of source code must retain the above copyright 1408 notice, this list of conditions and the following disclaimer. 1410 o Redistributions in binary form must reproduce the above copyright 1411 notice, this list of conditions and the following disclaimer in 1412 the documentation and/or other materials provided with the 1413 distribution. 1415 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1416 names of specific contributors, may be used to endorse or promote 1417 products derived from this software without specific prior 1418 written permission. 1420 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1421 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1422 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 1423 FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 1424 COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 1425 INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 1426 BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 1427 LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 1428 CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 1429 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN 1430 ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 1431 POSSIBILITY OF SUCH DAMAGE. 1433 BEGIN 1435 1437 1448 1450 1452 1454 1456 1458 1460 1464 1466 1470 1472 1474 1476 1478 1480 1482 1484 1486 1488 1489 1491 1493 1498 1500 1502 1504 1506 1509 1511 1513 1517 1519 1521 1523 1525 1527 1529 1531 1533 1535 1536 1538 1540 1542 1544 1546 1548 1550 1553 1555 1557 1559 1562 1565 1567 1569 1571 1575 1577 1579 1581 1582 1584 1586 1588 1590 1592 1594 1596 1598 END 1600 8.5. Reports Object 1602 Copyright (c) 2019 IETF Trust and the persons identified as authors 1603 of the code. All rights reserved. 1605 Redistribution and use in source and binary forms, with or without 1606 modification, are permitted provided that the following conditions 1607 are met: 1609 o Redistributions of source code must retain the above copyright 1610 notice, this list of conditions and the following disclaimer. 1612 o Redistributions in binary form must reproduce the above copyright 1613 notice, this list of conditions and the following disclaimer in 1614 the documentation and/or other materials provided with the 1615 distribution. 1617 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1618 names of specific contributors, may be used to endorse or promote 1619 products derived from this software without specific prior 1620 written permission. 1622 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1623 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1624 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 1625 FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 1626 COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 1627 INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 1628 BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 1629 LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 1630 CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 1631 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN 1632 ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 1633 POSSIBILITY OF SUCH DAMAGE. 1635 BEGIN 1637 1639 1649 1651 1653 1655 1657 1659 1661 1663 1665 1667 1669 1671 1673 1675 1677 1679 END 1681 8.6. Notifications Object 1683 Copyright (c) 2019 IETF Trust and the persons identified as authors 1684 of the code. All rights reserved. 1686 Redistribution and use in source and binary forms, with or without 1687 modification, are permitted provided that the following conditions 1688 are met: 1690 o Redistributions of source code must retain the above copyright 1691 notice, this list of conditions and the following disclaimer. 1693 o Redistributions in binary form must reproduce the above copyright 1694 notice, this list of conditions and the following disclaimer in 1695 the documentation and/or other materials provided with the 1696 distribution. 1698 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1699 names of specific contributors, may be used to endorse or promote 1700 products derived from this software without specific prior 1701 written permission. 1703 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1704 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1705 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 1706 FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 1707 COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 1708 INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 1709 BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 1710 LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 1711 CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 1712 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN 1713 ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 1714 POSSIBILITY OF SUCH DAMAGE. 1716 BEGIN 1718 1720 1732 1734 1738 1740 1742 1744 1746 1748 1750 1752 1754 1756 1758 1760 1762 1764 END 1766 9. Internationalization Considerations 1768 Data escrow deposits are represented in XML, which provides native 1769 support for encoding information using the Unicode character set and 1770 its more compact representations including UTF-8. Conformant XML 1771 processors recognize both UTF-8 and UTF-16. Though XML includes 1772 provisions to identify and use other character encodings through use 1773 of an "encoding" attribute in an declaration, use of UTF-8 1774 is RECOMMENDED. 1776 10. Security Considerations 1778 This specification does not define the security mechanisms to be 1779 used in the transmission of the data escrow deposits, since it only 1780 specifies the minimum necessary to enable the rebuilding of an IIIN 1781 from deposits without intervention from the original IIIN. 1783 Depending on local policies, some elements or most likely, the whole 1784 deposit will be considered confidential. As such the IIIN 1785 transmitting the data to the escrow agent SHOULD take all the 1786 necessary precautions like encrypting the data itself and/or the 1787 transport channel to avoid inadvertent disclosure of private data. 1789 It is also of the utmost importance the authentication of the 1790 parties passing data escrow deposit files. The escrow agent SHOULD 1791 properly authenticate the identity of the IIIN before accepting data 1792 escrow deposits. In a similar manner, the IIIN SHOULD authenticate 1793 the identity of the escrow agent before submitting any data. 1795 Additionally, the IIIN and the escrow agent SHOULD use integrity 1796 checking mechanisms to ensure the data transmitted is what the 1797 source intended. Validation of the contents by the escrow agent is 1798 RECOMMENDED to ensure not only the file was transmitted correctly 1799 from the IIIN, but also the contents are also "meaningful". 1801 11. IANA Considerations 1803 This document uses URNs to describe XML namespaces and XML schemas 1804 conforming to a registry mechanism described in [RFC3688]. Twelve 1805 URI assignments need to be registered by the IANA. 1807 Registration request for the INDE namespace: 1809 URI: urn:ietf:params:xml:ns:indea-1.0 1811 URI: urn:ietf:params:xml:ns:indeReport-1.0 1812 URI: urn:ietf:params:xml:ns:indeNotification-1.0 1814 URI: urn:ietf:params:xml:ns:indeRReport-1.0 1816 URI: urn:ietf:params:xml:ns:indeReports-1.0 1818 URI: urn:ietf:params:xml:ns:indeNotifications-1.0 1820 Registrant Contact: See the "Author's Address" section of this 1821 document. 1823 XML: None. Namespace URIs do not represent an XML specification. 1825 Registration request for the INDE XML schema: 1827 URI: urn:ietf:params:xml:schema:indea-1.0 1829 URI: urn:ietf:params:xml:schema:indeReport-1.0 1831 URI: urn:ietf:params:xml:schema:indeNotification-1.0 1833 URI: urn:ietf:params:xml:schema:indeRReport-1.0 1835 URI: urn:ietf:params:xml:schema:indeReports-1.0 1837 URI: urn:ietf:params:xml:schema:indeNotifications-1.0 1839 Registrant Contact: See the "Author's Address" section of this 1840 document. 1842 XML: See the "Formal Syntax" section of this document. 1844 12. Privacy Considerations 1846 This specification defines a format that may be used to escrow 1847 personal data. The process of data escrow is governed by a legal 1848 document agreed by the parties, and such legal document must 1849 regulate the particularities regarding the protection of personal 1850 data. 1852 13. References 1854 13.1. Normative References 1856 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1857 Requirement Levels",BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1858 March 1997, . 1859 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1860 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1861 . 1862 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 1863 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1864 May 2017, . 1865 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1866 DOI 10.17487/RFC3688, January 2004, 1867 . 1868 [I-D.draft-second-level-node-objects-mapping] HongJie Wu, Jian Chen, 1869 XiaoTian Fan, Meilan Chen, ZhiPing Li "Second-level Node (SLN) Data 1870 Objects Mapping",draft-second-level-node-objects-mapping-00 (work in 1871 progress). 1873 [I-D.draft-industrial-internet-identifier-data-escrow] HongJie Wu, 1874 Jian Chen, XiaoTian Fan, Meilan Chen, ZhiPing Li "Second-level Node 1875 (SLN) Data Objects Mapping", draft-industrial-internet-identifier- 1876 data-escrow-00 (work in progress). 1878 14. Acknowledgments 1880 This document reference draft [draft-ietf-regext-data-escrow-03], 1881 thus, would like to thank the draft author G. Lozano. And would like 1882 to thank X. Fan, J. Chen, C. Ma, M. Chen, Z. Li who provided special 1883 important suggestions and invaluable comments. This document was 1884 prepared using 2-Word-v2.0.template.dot. 1886 Authors' Addresses 1888 Hongjie Wu 1889 CAICT 1890 No.52 Huayuan North Road, Haidian District 1891 Beijing, Beijing, 100191 1892 China 1893 Phone: +86 186 0106 5934 1894 Email: wuhongjie@caict.ac.cn 1895 Jian Chen 1896 CAICT 1897 No.52 Huayuan North Road, Haidian District 1898 Beijing, Beijing, 100191 1899 China 1900 Phone: +86 138 1103 3332 1901 Email: chenjian3@caict.ac.cn 1903 Xiaotian Fan 1904 CAICT 1905 No.52 Huayuan North Road, Haidian District 1906 Beijing, Beijing, 100191 1907 China 1908 Phone: +86 134 0108 6945 1909 Email: fanxiaotian@caict.ac.cn 1911 Zhiping Li 1912 CAICT 1913 No.52 Huayuan North Road, Haidian District 1914 Beijing, Beijing, 100191 1915 China 1916 Phone: +86 185 1107 1386 1917 Email: lizhiping@caict.ac.cn 1919 Jiagui Xie 1920 CAICT 1921 No.52 Huayuan North Road, Haidian District 1922 Beijing, Beijing, 100191 1923 China 1924 Phone: +86 150 0138 5070 1925 Email: xiejiagui@caict.ac.cn