idnits 2.17.1 draft-ietf-regext-org-ext-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5731]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 5, 2017) is 2334 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 6982 (Obsoleted by RFC 7942) ** Downref: Normative reference to an Informational RFC: RFC 7451 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force L. Zhou 3 Internet-Draft N. Kong 4 Intended status: Standards Track J. Wei 5 Expires: June 8, 2018 X. Lee 6 CNNIC 7 J. Gould 8 VeriSign, Inc. 9 December 5, 2017 11 Organization Extension for the Extensible Provisioning Protocol (EPP) 12 draft-ietf-regext-org-ext-01 14 Abstract 16 This mapping, an extension to EPP object mappings like the EPP domain 17 name mapping [RFC5731], to support assigning an organization to any 18 existing object (domain, host, contact) as well as any future 19 objects. Specified in Extensible Markup Language (XML), this 20 extended mapping is applied to provide additional features required 21 for the provisioning of organizations. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 8, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 71 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 72 3.1. Organization Identifier . . . . . . . . . . . . . . . . . 4 73 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 4 74 4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 4 75 4.1.1. EPP Command . . . . . . . . . . . . . . . . . 4 76 4.1.2. EPP Command . . . . . . . . . . . . . . . . . 4 77 4.1.3. EPP Command . . . . . . . . . . . . . . . 7 78 4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 7 79 4.2.1. EPP Command . . . . . . . . . . . . . . . . 7 80 4.2.2. EPP Command . . . . . . . . . . . . . . . . 8 81 4.2.3. EPP Command . . . . . . . . . . . . . . . . . 8 82 4.2.4. EPP Command . . . . . . . . . . . . . . . 9 83 4.2.5. EPP Command . . . . . . . . . . . . . . . . 9 84 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 85 6. Internationalization Considerations . . . . . . . . . . . . . 13 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 14 88 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 14 89 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 90 8.1. CNNIC Impelementation . . . . . . . . . . . . . . . . . . 15 91 8.2. Reseller Extension . . . . . . . . . . . . . . . . . . . 15 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 93 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 96 11.2. Informative References . . . . . . . . . . . . . . . . . 17 98 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 101 1. Introduction 103 In the business model of domain registration, we usually have 3 roles 104 of entities, a registrant, a registrar and a registry. There may 105 have some other roles of entities involved in the domain registration 106 process which are not formally defined, such as resellers, DNS 107 service operators, privacy proxy, etc. 109 A domain reseller is an individual or a company that acts as a agent 110 for accredited registrars. A third-party DNS service operator is 111 responsible for a zone where the operator is neither the registrant 112 nor the registrar of records for the delegation. And a privacy proxy 113 is an entity that provides with individuals or organizations domain 114 registration without exposing their private information. These kind 115 of entities are defined as "organizations" with different role types 116 in this document. 118 In order to facilitate provisioning and management of organization 119 information in a shared central repository, this document proposes a 120 organization extension mapping for any EPP object like domain names 121 in [RFC5731], hosts in [RFC5732] and contacts in [RFC5733]. The 122 examples provided in this document are used for the domain object for 123 illustration purpose. The host and contact object could be extended 124 in the same way with the domain object. 126 A organization mapping object defined in [ID.draft-ietf-regext-org] 127 SHOULD be created first. The organization information specified in 128 this document MUST reference the existing organization identifier. 130 This document is specified using the XML 1.0 as described in 131 [W3C.REC-xml-20040204] and XML Schema notation as described in 132 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. 134 2. Conventions Used in This Document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 In examples, "C:" represents lines sent by a protocol client and "S:" 141 represents lines returned by a protocol server. Indentation and 142 white space in examples are provided only to illustrate element 143 relationships and are not a REQUIRED feature of this specification. 145 XML is case sensitive. Unless stated otherwise, XML specifications 146 and examples provided in this document MUST be interpreted in the 147 character case presented to develop a conforming implementation. 149 orgext-1.0 in this document is used as an abbreviation for 150 urn:ietf:params:xml:ns:orgext-1.0. 152 3. Object Attributes 154 This extension adds additional elements to the EPP domain name 155 mapping [RFC5731]. Only the new elements are described here. 157 3.1. Organization Identifier 159 Organization identifier provides the ID of an organization. Its 160 corresponding element is which refers to the 161 element defined in [ID.draft-ietf-regext-org]. All 162 organization objects are identified by a server-unique identifier. 164 4. EPP Command Mapping 166 A detailed description of the EPP syntax and semantics can be found 167 in the EPP core protocol specification [RFC5730]. The command 168 mappings described here are specifically for use in provisioning and 169 managing organization information via EPP. 171 4.1. EPP Query Commands 173 EPP provides three commands to retrieve domain information: 174 to determine if a domain object can be provisioned within a 175 repository, to retrieve detailed information associated with a 176 domain object, and to retrieve domain-object transfer 177 status information. 179 4.1.1. EPP Command 181 This extension does not add any elements to the EPP command 182 or response described in the EPP domain name mapping 183 [RFC5731], host mapping [RFC5732] and contact mapping [RFC5733]. 185 4.1.2. EPP Command 187 This extension does not add any element to the EPP command 188 described in the EPP domain mapping [RFC5731], host mapping [RFC5732] 189 and contact mapping [RFC5733]. However, additional elements are 190 defined for the response. 192 Example command: 194 C: 195 C: 196 C: 197 C: 198 C: 200 C: example.com 201 C: 202 C: fooBAR 203 C: 204 C: 205 C: 206 C: ngcl-mIFICBNP 207 C: 208 C: 210 When an command has been processed successfully, the EPP 211 element MUST contain child elements as described in the EPP 212 object extensions. In addition, the EPP element SHOULD 213 contain a child element that identifies the 214 extension namespace if the object has data associated with this 215 extension and based on its service policy. The 216 element contains the following child elements: 218 o A element that contains the identifier of the 219 organization. An attribute "role" associated with is 220 used to represent the relationship an organization would have. 221 See Section 7.3 in [ID.draft-ietf-regext-org] for a list of 222 values. 224 Example response for an authorized client: 226 S: 227 S: 228 S: 229 S: 230 S: Command completed successfully 231 S: 232 S: 233 S: 235 S: example.com 236 S: EXAMPLE1-REP 237 S: 238 S: jd1234 239 S: sh8013 240 S: sh8013 241 S: sh8013 242 S: 243 S: ns1.example.com 244 S: 245 S: ClientX 246 S: ClientY 247 S: 2015-02-06T04:01:21.0Z 248 S: 2018-02-06T04:01:21.0Z 249 S: 250 S: 2fooBAR 251 S: 252 S: 253 S: 254 S: 255 S: 257 S: myreseller 258 S: myproxy 259 S: 260 S: 261 S: 262 S: ngcl-IvJjzMZc 263 S: test142AWQONJZ 264 S: 265 S: 266 S: 268 An EPP error response MUST be returned if an command cannot be 269 processed for any reason. 271 4.1.3. EPP Command 273 This extension does not add any elements to the EPP 274 command or response described in the EPP domain name 275 mapping [RFC5731], host mapping [RFC5732] and contact mapping 276 [RFC5733]. 278 4.2. EPP Transform Commands 280 EPP provides five commands to transform domain objects: to 281 create an instance of a domain object, to delete an instance 282 of a domain object, to extend the validity period of a domain 283 object, to manage domain object sponsorship changes, and 284 to change information associated with a domain object. 286 4.2.1. EPP Command 288 This extension defines additional elements for the EPP 289 command described in the EPP object extensions. No additional 290 elements are defined for the EPP response. 292 The EPP command provides a transform operation that allows a 293 client to create an object. In addition to the EPP command elements 294 described in the EPP object extensions, the command MUST contain an 295 element, and the element MUST contain a child 296 element that identifies the extension namespace if 297 the client wants to associate data defined in this extension to the 298 object. The element contains the following child 299 elements: 301 o A element that contains the identifier of the 302 organization. An attribute "role" associated with is 303 used to represent the relationship an organization would have. 304 See Section 7.3 in [ID.draft-ietf-regext-org] for a list of 305 values. 307 Example Command: 309 C: 310 C: 311 C: 312 C: 313 C: 315 C: example.com 316 C: 3 317 C: 318 C: ns1.example.com 319 C: 320 C: jd1234 321 C: sh8013 322 C: sh8013 323 C: sh8013 324 C: 325 C: fooBAR 326 C: 327 C: 328 C: 329 C: 330 C: 332 C: myreseller 333 C: 334 C: 335 C: ABC-12345 336 C: 337 C: 339 When a command has been processed successfully, the EPP 340 response is as described in the EPP object extension. 342 An EPP error response MUST be returned if a command cannot 343 be processed for any reason. 345 4.2.2. EPP Command 347 This extension does not add any elements to the EPP command 348 or response described in the EPP domain mapping [RFC5731], 349 host mapping [RFC5732] and contact mapping [RFC5733]. 351 4.2.3. EPP Command 353 This extension does not add any elements to the EPP command 354 or response described in the EPP domain mapping [RFC5731], 355 host mapping [RFC5732] and contact mapping [RFC5733]. 357 4.2.4. EPP Command 359 This extension does not add any elements to the EPP 360 command or response described in the EPP domain mapping 361 [RFC5731], host mapping [RFC5732] and contact mapping [RFC5733], but 362 after a successful transfer of an object with an assigned 363 organization, the handling of the assigned organization is dependent 364 on the organization roles and server policy. 366 4.2.5. EPP Command 368 This extension defines additional elements for the EPP 369 command described in the EPP domain mapping [RFC5731], host mapping 370 [RFC5732] and contact mapping [RFC5733]. No additional elements are 371 defined for the EPP response. 373 The EPP command provides a transform operation that allows a 374 client to modify the attributes of a domain object. In addition to 375 the EPP command elements described in the EPP domain mapping, the 376 command MUST contain an element, and the 377 element MUST contain a child element that identifies 378 the extension namespace if the client wants to update the domain 379 object with data defined in this extension. The 380 element contains the following child elements: 382 o An OPTIONAL element that contains attribute values to 383 be added to the object. 385 o An OPTIONAL element that contains attribute values to 386 be removed from the object. 388 o An OPTIONAL element that contains attribute values to 389 be changed. 391 At least one and only one , or 392 element MUST be provided. The , and 393 elements contain the following child element: 395 o A element that contains the identifier of the 396 organization. An attribute "role" associated with is 397 used to represent the relationship an organization would have. 398 See Section 7.3 in [ID.draft-ietf-regext-org] for a list of 399 values. 401 Example command, adding a reseller: 403 C: 404 C: 405 C: 406 C: 407 C: 409 C: example.com 410 C: 411 C: 412 C: 413 C: 415 C: 416 C: myreseller 417 C: 418 C: 419 C: 420 C: ABC-12345 421 C: 422 C: 424 Example command, removing a reseller: 426 C: 427 C: 428 C: 429 C: 430 C: 432 C: example.com 433 C: 434 C: 435 C: 436 C: 438 C: 439 C: myreseller 440 C: 441 C: 442 C: 443 C: ABC-12345 444 C: 445 C: 447 Example command, updating reseller identifier: 449 C: 450 C: 451 C: 452 C: 453 C: 455 C: example.com 456 C: 457 C: 458 C: 459 C: 461 C: 462 C: myreseller 463 C: 464 C: 465 C: 466 C: ABC-12345 467 C: 468 C: 470 When an extended command has been processed successfully, 471 the EPP response is as described in the EPP object extension. 473 5. Formal Syntax 475 An EPP object mapping is specified in XML Schema notation. The 476 formal syntax presented here is a complete schema representation of 477 the object mapping suitable for automated validation of EPP XML 478 instances. The BEGIN and END tags are not part of the schema; they 479 are used to note the beginning and ending of the schema for URI 480 registration purposes. 482 BEGIN 483 485 492 495 497 500 501 502 Extensible Provisioning Protocol v1.0 503 Organization Extension Schema v1.0 504 505 507 508 509 511 514 515 516 518 519 520 522 524 528 529 530 532 534 536 537 539 540 541 544 545 546 548 550 552 554 556 557 558 560 562 563 565 567 568 569 END 571 6. Internationalization Considerations 573 EPP is represented in XML, which provides native support for encoding 574 information using the Unicode character set and its more compact 575 representations including UTF-8. Conformant XML processors recognize 576 both UTF-8 and UTF-16. Though XML includes provisions to identify 577 and use other character encodings through use of an "encoding" 578 attribute in an declaration, use of UTF-8 is RECOMMENDED. 580 As an extension of the EPP domain name mapping, the elements, element 581 content described in this document MUST inherit the 582 internationalization conventions used to represent higher-layer 583 domain and core protocol structures present in an XML instance that 584 includes this extension. 586 7. IANA Considerations 587 7.1. XML Namespace 589 This document uses URNs to describe XML namespaces and XML schemas 590 conforming to a registry mechanism described in [RFC3688]. IANA is 591 requested to assignment the following URI. 593 Registration request for the organization namespace: 595 o URI: urn:ietf:params:xml:ns:orgext-1.0 597 o Registrant Contact: See the "Author's Address" section of this 598 document. 600 o XML: See the "Formal Syntax" section of this document. 602 7.2. EPP Extension Registry 604 The EPP extension described in this document should be registered by 605 the IANA in the EPP Extension Registry described in [RFC7451]. The 606 details of the registration are as follows: 608 Name of Extension: Organization Extension 610 Document status: Standards Track 612 Reference: (insert reference to RFC version of this document) 614 Registrant Name and Email Address: See the "Author's Address" section 615 of this document. 617 TLDs: any 619 IPR Disclosure: none 621 Status: active 623 Notes: none 625 8. Implementation Status 627 Note to RFC Editor: Please remove this section and the reference to 628 [RFC6982] before publication. This section records the status of 629 known implementations of the protocol defined by this specification 630 at the time of posting of this Internet-Draft, and is based on a 631 proposal described in [RFC6982]. The description of mplementations 632 in this section is intended to assist the IETF in its decision 633 processes in progressing drafts to RFCs. Please note that the 634 listing of any individual implementation here does not imply 635 endorsement by the IETF. Furthermore, no effort has been spent to 636 verify the information presented here that was supplied by IETF 637 contributors. This is not intended as, and must not be construed to 638 be, a catalog of available implementations or their features. 639 Readers are advised to note that other implementations may exist. 641 According to [RFC6982], "this will allow reviewers and working groups 642 to assign due consideration to documents that have the benefit of 643 running code, which may serve as evidence of valuable experimentation 644 and feedback that have made the implemented protocols more mature. 645 It is up to the individual working groups to use this information as 646 they see fit". 648 CNNIC is in the process of development research to update 649 organization extension from reseller extension. Verisign is also 650 planning to implement this extension. 652 8.1. CNNIC Impelementation 654 Organization: CNNIC 656 Name: Organization Extension for EPP 658 Description: CNNIC is trying to update organizaiton extension from 659 previous reseller extension according to this document. 661 Level of maturity: Research. 663 Coverage: Organization extension for EPP. 665 Contact: zhouguiqing@cnnic.cn 667 8.2. Reseller Extension 669 This document was updated from draft-ietf-regext-reseller-ext. 670 CNNIC, Verisign and Patrick Mevzek have already implemented this 671 extension. 673 9. Security Considerations 675 The object mapping extension described in this document does not 676 provide any other security services or introduce any additional 677 considerations beyond those described by [RFC5730], [RFC5731], 678 [RFC5732] and [RFC5733] or those caused by the protocol layers used 679 by EPP. 681 10. Acknowledgement 683 The authors would like to thank Rik Ribbers, Marc Groeneweg, Patrick 684 Mevzek, Antoin Verschuren and Scott Hollenbeck for their careful 685 review and valuable comments. 687 11. References 689 11.1. Normative References 691 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 692 Requirement Levels", BCP 14, RFC 2119, 693 DOI 10.17487/RFC2119, March 1997, 694 . 696 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 697 DOI 10.17487/RFC3688, January 2004, 698 . 700 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 701 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 702 . 704 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 705 Domain Name Mapping", STD 69, RFC 5731, 706 DOI 10.17487/RFC5731, August 2009, 707 . 709 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 710 Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, 711 August 2009, . 713 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 714 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, 715 August 2009, . 717 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 718 Code: The Implementation Status Section", RFC 6982, 719 DOI 10.17487/RFC6982, July 2013, 720 . 722 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 723 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 724 February 2015, . 726 [W3C.REC-xml-20040204] 727 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 728 F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third 729 Edition)", World Wide Web Consortium FirstEdition REC-xml- 730 20040204", February 2004, 731 . 733 [W3C.REC-xmlschema-1-20041028] 734 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 735 ""XML Schema Part 1: Structures Second Edition", World 736 Wide Web Consortium Recommendation REC-xmlschema- 737 1-20041028", October 2004, 738 . 740 [W3C.REC-xmlschema-2-20041028] 741 Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes 742 Second Edition", World Wide Web Consortium Recommendation 743 REC-xmlschema-2-20041028", October 2004, 744 . 746 11.2. Informative References 748 [ID.draft-ietf-regext-org] 749 Zhou, L., Kong, N., Zhou, G., Lee, X., Gould, J., and S. 750 Hollenbeck, "Extensible Provisioning Protocol (EPP) 751 Reseller Mapping", Apr 2017, 752 . 754 Appendix A. Change Log 756 Initial -00: Individual document submitted. 758 -01: 760 * Updated abstract and introduction. 762 * Revised typos in info response. 764 * Added explanations on how to process reseller extension after 765 successful transfer operation. 767 * Modified explanation. 769 * Deleted reseller name element in and 770 commands. 772 * Removed some inaccurate comments from xml schema. 774 * Modified the element name of reseller id and reseller name. 776 -02: 778 * Changed author information. 780 * Updated xml typos to 781 in response. 783 -03: 785 * Changed author information. 787 * Updated section 3.1. 789 * Removed reseller name element in response. 791 * Added acknowledgement. 793 * Revised the typo "resellerr" to "resellerext". 795 WG document-00: WG document submitted 797 WG document-01: Keep document alive for further discussion. The 798 requirement of reseller information is clear for both registrar 799 and registry. What we should reach a consensus is whether the 800 extension should support only a name or ID and name. 802 Organization WG document-00: Change to a generic organization object 803 extension. 805 Organization WG document-01: Added "Imeplementation Status" section. 807 Authors' Addresses 809 Linlin Zhou 810 CNNIC 811 4 South 4th Street, Zhongguancun, Haidian District 812 Beijing, Beijing 100190 813 China 815 Phone: +86 10 5881 2677 816 Email: zhoulinlin@cnnic.cn 817 Ning Kong 818 CNNIC 819 4 South 4th Street, Zhongguancun, Haidian District 820 Beijing, Beijing 100190 821 China 823 Phone: +86 10 5881 3147 824 Email: nkong@cnnic.cn 826 Junkai Wei 827 CNNIC 828 4 South 4th Street, Zhongguancun, Haidian District 829 Beijing, Beijing 100190 830 China 832 Phone: +86 10 5881 3494 833 Email: weijunkai@cnnic.cn 835 Xiaodong Lee 836 CNNIC 837 4 South 4th Street, Zhongguancun, Haidian District 838 Beijing, Beijing 100190 839 China 841 Phone: +86 10 5881 3020 842 Email: xl@cnnic.cn 844 James Gould 845 VeriSign, Inc. 846 12061 Bluemont Way 847 Reston, VA 20190 848 US 850 Email: jgould@verisign.com