idnits 2.17.1 draft-wu-identifier-sln-objects-mapping-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 1033 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force H. Wu 2 Internet Draft Z. Li 3 Intended status: Experimental J. Chen 4 Expires: December 21 2021 X. Fan 5 China Academy of Information and Communications Technology 6 June 21, 2021 7 Second-level Node (SLN) Data Objects Mapping 8 draft-wu-identifier-sln-objects-mapping-03 10 Abstract 12 This document specifies the format, contents and semantics of data 13 escrow deposits for Industrial Internet Identifier Second-level Node 14 (SLN). SLN directly serves enterprises and provides services such as 15 identifier registration, identifier resolution, data sharing, etc. 16 The mapping objects in this document mainly refers to the enterprise 17 registration information of the SLN and the Enterprise-level Node 18 (ELN) registered in the SLN. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as 33 reference material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on December 21, 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with 53 respect to this document. Code Components extracted from this 54 document must include Simplified BSD License text as described in 55 Section 4.e of the Trust Legal Provisions and are provided without 56 warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction ................................................ 2 61 2. Model ....................................................... 3 62 3. Conventions used in this document............................ 4 63 4. General Conventions ......................................... 4 64 4.1. Date and Time .......................................... 4 65 4.2. IP Address ............................................. 4 66 4.3. Country names .......................................... 4 67 4.4. Telephone numbers....................................... 4 68 4.5. Internationalized and Localized Elements................ 5 69 5. Object Description .......................................... 5 70 5.1. Node Object ............................................ 5 71 5.1.1. XML Model ......................................... 5 72 5.1.1.1. element....................... 5 73 5.1.1.2. object...................... 9 74 5.2. Header Object .......................................... 9 75 5.2.1. object........................ 10 76 6. Profile .................................................... 11 77 7. Data escrow agent extended verification process............. 11 78 8. Formal Syntax .............................................. 12 79 8.1. INDE Node Object....................................... 12 80 8.2. Header Object ......................................... 20 81 9. Internationalization Considerations......................... 23 82 10. Security Considerations.................................... 23 83 11. IANA Considerations........................................ 24 84 12. Privacy Considerations..................................... 24 85 13. Example of a full deposit using the XML model.............. 25 86 14. Example of differential deposit using the XML model........ 29 87 15. References ................................................ 32 88 15.1. Normative References.................................. 32 89 15.2. Informative References................................ 32 90 16. Acknowledgments ........................................... 33 92 1. Introduction 94 Second-level Node (SLN) Data Escrow is the process by which an SLN 95 periodically submits data deposits to a third-party called an escrow 96 agent. These deposits comprise the minimum data needed by a third- 97 party to resume operations if the SLN cannot function and is unable 98 or unwilling to facilitate an orderly transfer of service. 100 The goal of data escrow is higher resiliency of registration 101 services, for the benefit of Internet users. The beneficiaries of a 102 SLN are not just those registering information there, but all 103 relying parties that need to identify the owners of objects. 105 This document defines the data escrow structure of the standard set 106 of objects for Industrial Internet Identifier Nodes which include 107 Second-level Node (SLN) and Enterprise-level Node (ELN). 109 This document defines the following object: 111 o Node: Including the enterprise registration information of the 112 SLN and the ELN registered in SLN. 114 This document defines the following pseudo-object: 116 o Header: Used to specify counters of objects in the database at a 117 certain point in time (watermark). 119 In the context of industry identifier namespace, data escrow is a 120 requirement for SLN. There is also a similar requirement for SLN 121 accredited identifier registration node. 123 This document specifies a format for data escrow deposits 124 independent of the objects being escrowed. A specification is 125 required for each type of registry/set of objects that is expected 126 to be escrowed. 128 2. Model 130 This document defines XML model be used to deposit data escrow 131 objects. The XML model includes all the deposit information (meta- 132 data and data) in an XML document. The definition of the XML format 133 is fully defined in the XML schemas. As a convention, the objects 134 represented using the XML model are referenced using INDE and an XML 135 namespace that is prefixed with "inde". For example, the SLN 136 enterprise registration information represented using the XML model 137 can be referred to as the INDE Node with the XML namespace including 138 indeNode (urn:ietf:params:xml:ns:indeNode-1.0). 140 3. Conventions used in this document 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in 145 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 SECOND-LEVEL NODE (SLN). In the context of this draft the definition 149 will indicate an organization providing Registry Services for a 150 second level identifier. 152 REGISTRY SERVICES. Services offered by the SLN critical to the 153 following tasks: responding to enterprise node queries for status 154 information relating to the servers for identifier; responding to 155 queries for enterprise information concerning identifier 156 registrations in the SLN. Any other products or services that only 157 an SLN is capable of providing by reason of its designation as a 158 SLN. Typical example of Services is: Identifier Resolving. 160 4. General Conventions 162 4.1. Date and Time 164 Numerous fields indicate "dates", such as the creation and expiry 165 dates for objects. These fields SHALL contain timestamp indicating 166 the date and time in UTC, specified in Internet Date/Time Format 167 (see [RFC3339], Section 5.6) with the time-offset specified as "Z". 169 4.2. IP Address 171 The syntax for IPv4 addresses described in this document MUST 172 conform to [RFC5730]. The syntax for IPv6 addresses described in 173 this document MUST conform to [RFC4291]. Practical considerations 174 for publishing IPv6 address information in zone files are documented 175 in [RFC2874] and [RFC3596]. A server MAY reject IP addresses that 176 have not been allocated for public use by IANA. 178 4.3. Country names 180 Country identifiers SHALL be represented using two characters 181 identifiers as specified in [ISO-3166-1]. 183 4.4. Telephone numbers 185 Telephone numbers (both voice and facsimile) SHALL be formatted 186 based on structures defined in [ITU-E164]. Telephone numbers 187 described in this specification are character strings that MUST 188 begin with a plus sign ("+", ASCII value 0x002B), followed by a 189 country code defined in [ITU-E164], followed by a dot (".", ASCII 190 value 0x002E), followed by a sequence of digits representing the 191 telephone number. 193 4.5. Internationalized and Localized Elements 195 Some elements MAY be provided in either internationalized form 196 ("int") or provided in localized form ("loc"). This MAY override the 197 form specified for a parent element. A value of "int" is used to 198 indicate the internationalized form and a value of "loc" is used to 199 indicate the localized form. When the internalized form ("int") is 200 provided, the field value MUST be represented in a subset of UTF-8 201 that can be represented in the 7-bit US-ASCII character set. When 202 the localized form ("loc") is provided, the field value MAY be 203 represented in unrestricted UTF-8. 205 5. Object Description 207 This section describes the base objects supported by this 208 specification: 210 5.1. Node Object 212 The node object represents the enterprise registration information 213 of a Second-level Node or Enterprise-level Node, and this element 214 supports XML Model. 216 5.1.1. XML Model 218 There are two elements used in the data escrow in the node objects 219 of the XML model including the , under the 220 element, and the element, under 221 the element. 223 A element substitutes for the 224 abstract element to define a concrete 225 definition of a identifier node. The element 226 can be replaced by other node definitions using the XML schema 227 substitution groups feature. 229 5.1.1.1. element 231 The element contains a "type" attribute to identify the node 232 is a Second-level Node or Enterprise-level Node. If a Second-level 233 Node (type="sec") is provided, element content MUST be Second-level 234 Node information. If an Enterprise-level Node (type="ent") is 235 provided, element content be Enterprise-level Node information. The 236 element contains the following child elements: 238 o A element contains the node-unique identifier of the 239 node object. 241 o A element contains the name of the enterprise. 243 o A element contains the enterprise nature. 245 o An element contains the enterprise address information. 246 This element content MUST be represented in a subset of UTF-8 247 that can be represented in the 7-bit US-ASCII character set. The 248 element contains the following child elements: 250 One, or two OPTIONAL elements contain the enterprise's 251 street address 253 A element contains the enterprise's city. 255 An OPTIONAL element contains the enterprise's state or 256 province. 258 A element contains the enterprise's two-letter country 259 code. 261 o Zero or more elements that contain enterprise's IP 262 address. The element contains the following child 263 elements: 265 An element contains the IP address. 267 A element contains the network port. 269 o A element. A required "type" attribute is used to identify 270 the credentials owner: Enterprise or Enterprise Legal Person. If 271 a (type="ent") is provided, element content MUST be enterprise's 272 credentials type. If a (type="leg") is provided, element content 273 MUST be enterprise's legal person credentials type. The 274 element contains the following child elements: 276 A element contains the credentials Type. 278 A element contains the credentials Number. 280 o A element contains the enterprise legal person Name. 282 o A element contains the enterprise's brief introduction. 284 o A element contains the enterprise's contact 285 information. The element contains the following child 286 elements: 288 A element contains the contact name. 290 A element that contains the contact phone. 292 A element that contains the contact email address. 294 o A element contains the enterprise's node register date. 296 o Zero or One element contains the enterprise's node 297 information update date. 299 Example of object: 301 ... 303 305 86.100 307 CAICT 309 Research Institute 311 313 Gaozhang Road 315 No.52 Huayuan North Road 317 319 Beijing 321 Beijing 323 CN 325 327 328 10.23.23.2 330 8080 332 334 336 10.23.23.1 338 8081 340 342 344 BusinessLicense 346 62072231123451 348 350 352 ChineseIDCard 354 121333343243223335 356 358 San.Zhang 360 362 It is the driving force of industrial development to undertake 363 the top node and the bridge of enterprises 365 367 369 Jonh 371 15911112222 373 123@123.com 375 377 2019-12-11T11:49:00.0Z 379 2019-12-12T17:51:00.0Z 381 383 ... 385 5.1.1.2. object 387 The element contains the SLN identifier that was 388 deleted. 390 Example of object: 392 ... 394 396 ... 398 400 86.200.2 402 404 406 86.200.1 408 410 ... 412 414 ... 416 5.2. Header Object 418 The Header Object is a pseudo-object that is used to specify the 419 number of objects in the repository at a specific point in time 420 (watermark) regardless of the type of deposit: differential or full. 421 The Header Object may also be used to provide additional information 422 on the contents of the deposit. The Header Object is only defined as 423 XML, but one header object MUST always be present per escrow deposit 424 regardless of using XML Model. The Header Object is defined using 425 the element. 427 5.2.1. object 429 The contains the following elements: 431 o A choice of one of the elements defined in the 432 "repositoryTypeGroup" group element that indicates the unique 433 identifier for the repository being escrowed. Possible elements: 435 A element that defines Second-level Node 436 Prefix being escrowed. 438 A element that defines Enterprise-level Node 439 prefix registered in Second-level. 441 A element that defines the provider ID 442 corresponding to a Reseller data escrow deposit. 444 o A element that contains the number of objects in the SLN 445 System at a specific point in time (watermark) regardless of the 446 type of deposit: differential or full. The element 447 supports the following attributes: 449 An "uri" attribute to reflect the XML namespace URI of the 450 primary objects of the XML Model. For example, the "uri" is set 451 to "urn:ietf:params:xml:ns:indeNode-1.0" for Node objects using 452 the XML Model. 454 An OPTIONAL "inp" attribute indicates the identifier node 455 prefix of the object included in the element. 457 o An PTIONAL element that contains a tag that defines 458 the expected content in the deposit. The producer and consumer of 459 the deposits will coordinate the set of possible 460 element values 462 Example of object referencing only the XML Model 463 objects: 465 ... 467 468 86.200 470 2 474 476 478 ... 480 6. Profile 482 Different business models of SLN exist, therefore the SLN is 483 responsible to define a profile that matches its particular business 484 model. The profile mechanism allows an SLN to extend this 485 specification. 487 A profile is the process of: 489 o Extending base objects with the mechanisms defined for XML model. 491 For XML model, abstract elements could be used to extend the 492 object using XML schema substitution groups feature. 494 o Adding new escrowed objects using the and 495 elements. 497 o Providing the XML schemas to third parties that require them to 498 validate the escrow deposits. 500 7. Data escrow agent extended verification process 502 A Data Escrow Agent SHOULD perform an extended verification process 503 that starts by creating a dataset to be tested. 505 o If a full deposit is to be tested, the full deposit is the 506 dataset. 508 o If a differential deposit is to be tested, the dataset is created 509 by using the differential deposit plus all the required deposits 510 leading to the last previous full deposit. 512 The following are the minimum suggested tests on the dataset: 514 o Validate the escrow deposits using the definition agreed with the 515 SLN. 517 In the case of the XML model, the contents of the escrow 518 deposits MUST be validated using the XML schemas of the 519 profile. 521 o Count the objects and validate that the number of objects is 522 equal to the number objects reported in the
element of 523 the escrow deposit of that point in time (watermark). 525 o The elements listed as required in the element MUST be 526 present. 528 o Providing the XML schemas to third parties that require them to 529 validate the escrow deposits. 531 o The watermark is not in the future. 533 8. Formal Syntax 535 8.1. INDE Node Object 537 Copyright (c) 2019 IETF Trust and the persons identified as authors 538 of the code. All rights reserved. 540 Redistribution and use in source and binary forms, with or without 541 modification, are permitted provided that the following conditions 542 are met: 544 o Redistributions of source code must retain the above copyright 545 notice, this list of conditions and the following disclaimer. 547 o Redistributions in binary form must reproduce the above copyright 548 notice, this list of conditions and the following disclaimer in 549 the documentation and/or other materials provided with the 550 distribution. 552 o Neither the name of Internet Society, IETF or IETF Trust, nor the 553 names of specific contributors, may be used to endorse or promote 554 products derived from this software without specific prior 555 written permission. 557 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 558 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 559 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 560 FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 561 COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 562 INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 563 BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 564 LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 565 CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 566 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN 567 ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 568 POSSIBILITY OF SUCH DAMAGE. 570 BEGIN 572 574 584 586 588 590 592 594 Identifier Second-level Node Data Escrow provisioning Schema 596 598 600 606 609 613 615 617 619 621 623 627 631 635 643 647 651 655 659 663 667 669 671 673 675 677 679 681 683 685 687 689 691 693 695 697 699 701 702 704 706 708 710 712 714 716 718 724 726 728 730 732 734 736 738 740 742 744 746 748 749 751 753 755 757 759 761 763 765 767 769 771 773 775 777 779 781 783 785 787 789 791 793 795 797 799 801 803 805 807 809 811 813 817 819 821 823 825 827 829 831 833 835 837 839 842 845 848 850 852 854 856 859 861 863 865 867 869 871 873 875 877 879 881 883 885 887 889 891 893 895 897 899 901 903 905 907 909 911 913 915 917 923 925 927 929 931 933 END 935 8.2. Header Object 937 Copyright (c) 2019 IETF Trust and the persons identified as authors 938 of the code. All rights reserved. 940 Redistribution and use in source and binary forms, with or without 941 modification, are permitted provided that the following conditions 942 are met: 944 o Redistributions of source code must retain the above copyright 945 notice, this list of conditions and the following disclaimer. 947 o Redistributions in binary form must reproduce the above copyright 948 notice, this list of conditions and the following disclaimer in 949 the documentation and/or other materials provided with the 950 distribution. 952 o Neither the name of Internet Society, IETF or IETF Trust, nor the 953 names of specific contributors, may be used to endorse or promote 954 products derived from this software without specific prior 955 written permission. 957 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 958 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 959 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 960 FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 961 COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 962 INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 963 BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 964 LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 965 CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 966 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN 967 ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 968 POSSIBILITY OF SUCH DAMAGE. 970 BEGIN 972 974 984 986 987 989 Identifier Second-level Node Escrow Deposit Header Schema 991 993 995 997 1001 1003 1005 1007 1009 1011 1013 1017 1019 1021 1023 1025 1027 1029 1031 1033 1034 1036 1038 1040 1042 1044 1046 1048 1050 1052 1054 1056 1058 END 1060 9. Internationalization Considerations 1062 Data escrow deposits are represented in XML, which provides native 1063 support for encoding information using the Unicode character set and 1064 its more compact representations including UTF-8. Conformant XML 1065 processors recognize both UTF-8 and UTF-16. Though XML includes 1066 provisions to identify and use other character encodings through use 1067 of an "encoding" attribute in an declaration, use of UTF-8 1068 is RECOMMENDED. 1070 10. Security Considerations 1072 This specification does not define the security mechanisms to be 1073 used in the transmission of the data escrow deposits, since it only 1074 specifies the minimum necessary to enable the rebuilding of an IIIN 1075 from deposits without intervention from the original IIIN. 1077 Depending on local policies, some elements or most likely, the whole 1078 deposit will be considered confidential. As such the IIIN 1079 transmitting the data to the escrow agent SHOULD take all the 1080 necessary precautions like encrypting the data itself and/or the 1081 transport channel to avoid inadvertent disclosure of private data. 1083 It is also of the utmost importance the authentication of the 1084 parties passing data escrow deposit files. The escrow agent SHOULD 1085 properly authenticate the identity of the IIIN before accepting data 1086 escrow deposits. In a similar manner, the IIIN SHOULD authenticate 1087 the identity of the escrow agent before submitting any data. 1089 Additionally, the IIIN and the escrow agent SHOULD use integrity 1090 checking mechanisms to ensure the data transmitted is what the 1091 source intended. Validation of the contents by the escrow agent is 1092 RECOMMENDED to ensure not only the file was transmitted correctly 1093 from the IIIN, but also the contents are also "meaningful". 1095 11. IANA Considerations 1097 This document uses URNs to describe XML namespaces and XML schemas 1098 conforming to a registry mechanism described in [RFC3688]. Four URI 1099 assignments need to be registered by the IANA. 1101 Registration request for the INDE namespace: 1103 URI: urn:ietf:params:xml:ns:indeNode-1.0 1105 URI: urn:ietf:params:xml:ns:indeHeader-1.0 1107 Registrant Contact: See the "Author's Address" section of this 1108 document. 1110 XML: None. Namespace URIs do not represent an XML specification. 1112 Registration request for the INDE XML schema: 1114 URI: urn:ietf:params:xml:schema:indeNode-1.0 1116 URI: urn:ietf:params:xml:schema:indeHeader-1.0 1118 Registrant Contact: See the "Author's Address" section of this 1119 document. 1121 XML: See the "Formal Syntax" section of this document. 1123 12. Privacy Considerations 1125 This specification defines a format that may be used to escrow 1126 personal data. The process of data escrow is governed by a legal 1127 document agreed by the parties, and such legal document must 1128 regulate the particularities regarding the protection of personal 1129 data. 1131 13. Example of a full deposit using the XML model 1133 1135 1143 2019-12-22T00:00:00Z 1145 1147 1.0 1149 urn:ietf:params:xml:ns:indeHeader-1.0 1151 1153 urn:ietf:params:xml:ns:indeNode-1.0 1155 1157 1159 1161 1163 1165 1167 86.100 1169 2 1173 1175 1177 1179 1181 86.100 1183 CAICT 1185 Research Institute 1187 1189 ChangAn Road 1191 HuaYuan Road 1193 Beijing 1195 Beijing 1197 CN 1199 1201 1203 10.23.23.2 1205 8080 1207 1209 1211 10.23.23.1 1213 8081 1215 1217 1219 BusinessLicense 1221 62072231123451 1223 1225 1227 ChineseIDCard 1229 121333343243223335 1231 1233 San.Zhang 1235 It is the driving force of industrial 1236 development to undertake the top node and the bridge of 1237 enterprises 1239 1241 1243 Jonh 1245 15911112222 1247 123@123.com 1249 1251 2019-11-23T11:49:00.0Z 1253 2019-12-12T17:51:00.0Z 1255 1257 1259 1261 86.100.1 1263 Tele 1265 Research Institute 1267 1269 ChangAn Road 1270 HuaYuan Road 1272 Beijing 1274 Beijing 1276 CN 1278 1280 1282 10.23.21.1 1284 8080 1286 1288 1290 10.23.23.1 1292 8081 1294 1296 1298 BusinessLicense 1300 62072231124321 1302 1304 1306 ChineseIDCard 1308 1213333432431213456 1310 1312 San.Zhang 1314 It is the driving force of industrial 1315 development to undertake the top node and the bridge of 1316 enterprises 1318 1320 1322 Jonh 1324 15911114321 1326 1233@123.com 1328 1330 2019-04-23T11:49:00.0Z 1332 2019-12-12T17:51:00.0Z 1334 1336 1338 1340 14. Example of differential deposit using the XML model 1342 1344 1352 2019-12-22T00:00:00Z 1354 1356 1.0 1358 urn:ietf:params:xml:ns:indeHeader-1.0 1360 1362 urn:ietf:params:xml:ns:indeNode-1.0 1364 1365 1367 1369 1371 86.200 1373 1375 1377 1379 1381 1383 1385 86.202 1387 1 1391 1393 1395 1397 1399 86.202 1401 CAICT 1403 Research Institute 1405 1407 ChangAn Road 1409 Beijing 1411 Beijing 1412 CN 1414 1416 1418 10.23.23.2 1420 8080 1422 1424 1426 10.23.23.1 1428 8081 1430 1432 1434 BusinessLicense 1436 62072231123451 1438 1440 1442 ChineseIDCard 1444 121333343243223335 1446 1448 San.Zhang 1450 It is the driving force of industrial 1451 development to undertake the top node and the bridge of 1452 enterprises 1454 1456 1458 Jonh 1459 15911112222 1461 123@123.com 1463 1465 2019-04-23T11:49:00.0Z 1467 2019-12-12T17:51:00.0Z 1469 1471 1473 1475 15. References 1477 15.1. Normative References 1479 [ISO-3166-1] 3166, I. S., "Codes for the representation of names of 1480 countries and their subdivisions -- Part 1: Country 1481 codes", ISO Standard 3166, November 2006. 1483 [ITU-E164] International Telecommunication Union, "The international 1484 public telecommunication numbering plan", ITU-T 1485 Recommendation E.164, February 2005. 1487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1488 Requirement Levels",BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1489 March 1997, . 1490 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1491 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1492 . 1493 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 1494 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1495 May 2017, . 1496 15.2. Informative References 1498 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1499 DOI 10.17487/RFC3688, January 2004, 1500 . 1501 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1502 Architecture", RFC 4291, February 2006. 1503 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1504 STD 69, RFC 5730, August 2009. 1505 [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support 1506 IPv6 Address Aggregation and Renumbering", RFC 2874, July 1507 2000. 1508 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1509 "DNS Extensions to Support IP Version 6", RFC 3596, 1510 October 2003. 1511 16. Acknowledgments 1513 This document reference draft [draft-ietf-regext-data-escrow-03], 1514 thus, would like to thank the draft author G. Lozano. And would like 1515 to thank X. Fan, J. Chen, C. Ma, M. Chen, Z. Li who provided special 1516 important suggestions and invaluable comments. This document was 1517 prepared using 2-Word-v2.0.template.dot. 1519 Authors' Addresses 1521 Hongjie Wu 1522 CAICT 1523 No.52 Huayuan North Road, Haidian District 1524 Beijing, Beijing, 100191 1525 China 1527 Phone: +86 186 0106 5934 1528 Email: wuhongjie@caict.ac.cn 1530 Jian Chen 1531 CAICT 1532 No.52 Huayuan North Road, Haidian District 1533 Beijing, Beijing, 100191 1534 China 1536 Phone: +86 138 1103 3332 1537 Email: chenjian3@caict.ac.cn 1539 Xiaotian Fan 1540 CAICT 1541 No.52 Huayuan North Road, Haidian District 1542 Beijing, Beijing, 100191 1543 China 1545 Phone: +86 134 0108 6945 1546 Email: fanxiaotian@caict.ac.cn 1547 Meilan Chen 1548 CAICT 1549 No.52 Huayuan North Road, Haidian District 1550 Beijing, Beijing, 100191 1551 China 1553 Phone: +86 139 1143 7301 1554 Email: chenmeilan@caict.ac.cn 1556 Zhiping Li 1557 CAICT 1558 No.52 Huayuan North Road, Haidian District 1559 Beijing, Beijing, 100191 1560 China 1562 Phone: +86 185 1107 1386 1563 Email: lizhiping@caict.ac.cn