idnits 2.17.1 draft-liu-epp-ustld-00.txt: -(80): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(169): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(296): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(437): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 17 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2002) is 8106 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '4-6' on line 89 -- Looks like a reference, but probably isn't: 'TBD' on line 518 == Unused Reference: '4' is defined on line 533, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-provreg-epp-06 == Outdated reference: A later version (-07) exists of draft-ietf-provreg-epp-domain-04 == Outdated reference: A later version (-07) exists of draft-ietf-provreg-epp-contact-04 == Outdated reference: A later version (-07) exists of draft-ietf-provreg-epp-host-03 == Outdated reference: A later version (-06) exists of draft-ietf-provreg-epp-tcp-04 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Provisioning Registry Protocol Working Group Hong Liu 3 Internet Draft Ning Zhang 4 Document: Tom McGarry 5 Category: Informational Joseph Amsden 6 Ayesha Damaraju 7 NeuStar, Inc. 8 Expires in six months February 2002 10 New EPP Parameters for the usTLD 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026 [1]. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 To learn the current status of any Internet-Draft, please check 37 the "1id-abstracts.txt" listing contained in the Internet-Drafts 38 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 39 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 40 Coast), or ftp.isi.edu (US West Coast). 42 Expires August 2002 1 43 New EPP Parameters for the usTLD February 2002 45 Abstract 47 This document defines two new EPP parameters to enable the exchange 48 of additional information between the registry and the registrars for 49 the United States ccTLD (usTLD). These two new parameters only apply 50 to contact objects served as registrants for usTLD domains. This is 51 accomplished according to the EPP extension framework in the command- 52 response field. 54 Terminology 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC 2119[2]. 60 In examples, "C:" represents lines sent by a protocol client and "S:" 61 represents lines returned by a protocol server. Indentation and white 62 space in examples is provided only to show element relationships and 63 is not a REQUIRED feature of the protocol. 65 Table of Contents 67 1. Introduction ................................................ 2 68 2. EPP Extensions for usTLD .................................... 3 69 3. Server Defined Extensions ................................... 3 70 3.1. AppPurpose Parameter....................................... 4 71 3.2. Nexus Parameter............................................ 4 72 4. EPP Commands ................................................ 5 73 5. Information Checking ........................................ 6 74 6. Examples .................................................... 7 75 7. Internationalization Considerations ......................... 9 76 8. IANA Considerations ......................................... 9 77 9. Security Considerations ..................................... 9 78 10. Acknowledgements ........................................... 9 79 11. References ................................................. 9 80 12. Author�s Address .......................................... 10 81 Revisions From Previous Versions .............................. 11 82 Full Copyright Statements ..................................... 11 84 1. Introduction 86 EPP (i.e., Extensible Provisioning Protocol) defines an extensible 87 registry-registrar protocol for domain name registrations. It 88 consists of a suite of documents: the generic protocol framework 89 [3], and the object mappings for domain, host and contact [4-6], 90 and the transport mapping to TCP [7]. 92 The EPP extension framework allows registry specific features to 93 be added at three levels: protocol, object and command-response 94 [3]. The extensions made to EPP for the usTLD is at the command- 95 response level. Specifically, two new information elements are 96 added to the field in the contact object. 98 The intent of this document is to specify the protocol elements in 99 EPP extensions in order to accommodate additional information 100 required for a registrar to interconnect with the usTLD registry 101 via an EPP-compatible interface. Specifically, the document 103 Expires August 2002 2 104 New EPP Parameters for the usTLD February 2002 106 defines two new EPP parameters for contact objects to be used as 107 registrants for usTLD domains. The first parameter describes the 108 intended purpose of the domain name, while the second specifies 109 the Nexus category to which the registering organization belongs. 110 Both are defined as parameters within the command-response 111 field for the contact object [6], according to the EPP 112 extension framework outlined in [3]. 114 For more information about usTLD and Nexus requirements, please 115 refer to [8] and [9]. 117 2. EPP Extensions for the usTLD 119 The EPP extensions for the usTLD are in the contact object mapping 120 [5] at the command-response level. The extension template for the 121 contact object is outlined below. 123 C: 124 C: 128 C: 129 C: 130 C: 131 C: 132 C: 133 C: 134 C: ABC-12345 135 C: 136 C: 138 S: 139 S: 140 S: Command completed successfully 141 S: 142 S: 143 S: 144 S: 145 S: 146 S: ABC-12345 147 S: 54321-XYZ 148 S: 149 S: 151 The extensions for the usTLD are accomplished by defining two new 152 elements within the field. Three EPP commands are 153 affected by the extensions for the contact object. 155 3. Server-Defined Elements 157 Two parameters are defined for conveying information in the 158 field; AppPurpose and NexusCategory. They are 159 specified as name-value pairs within as follows: 161 Expires August 2002 3 162 New EPP Parameters for the usTLD February 2002 164 165 AppPurpose=value 166 NexusCategory=value 167 169 Here �value� is a character string to be defined in Sections 3.1 170 and 3.2, respectively. When both parameters are present in the 171 field, they are separated by at least one white space 172 character. 174 3.1 AppPurpose Parameter 176 The AppPurpose (i.e., Application Purpose) parameter specifies the 177 intended usage for the domain name. The set of defined values for 178 this parameter is: 180 - �P1�: Business use for profit; 182 - �P2�: Non-profit business, club, association, religious 183 organization, etc.; 185 - �P3�: Personal use; 187 - �P4�: Educational purposes; 189 - �P5�: Government purposes. 191 3.2 Nexus Parameter 193 Qualifying registrants for the usTLD fall into one of the three 194 categories: 196 - Nexus Category 1 198 A natural person (i) who is a US citizen, (ii) a permanent 199 resident of the US or any of its possessions or territories, or 200 (iii) whose primary place of domicile is in the US or any of 201 its possessions. 203 - Nexus Category 2 205 An entity or organization that is (i) incorporated within one 206 of the fifty US states, the District of Columbia, or any of the 207 US possessions or territories, or (ii) organized or otherwise 208 constituted under the laws of a state of the US, the District 209 of Columbia or any of its possessions and territories 210 (including federal, state, or local government of the US, or a 211 political subdivision thereof, and non-commercial organizations 212 based in the US.) 214 - Nexus Category 3 216 A foreign entity or organization that has a bona fide presence 217 in the US or any of its possessions or territories, and that 218 has substantial lawful contacts with, or lawful activities in, 219 the US. 221 Expires August 2002 4 222 New EPP Parameters for the usTLD February 2002 224 Nexus information is required for the registrants to ensure that 225 only those individuals or organizations that have a substantive 226 lawful connection to the US are permitted to register for usTLD 227 domain names. 229 The NexusCategory parameter specifies the Nexus category or sub- 230 category to which the registrant belongs. The set of defined 231 values for this parameter is: 233 - �C11�: A natural person who is a US Citizen; 235 - �C12�: A natural person who is a Permanent Resident; 237 - �C21�: An entity or organization that is (i) incorporated 238 within one of the fifty US states, the District of Columbia, or 239 any of the US possessions or territories, or (ii) organized or 240 otherwise constituted under the laws of a state of the US, the 241 District of Columbia or any of its possessions and territories 242 (including federal, state, or local government of the US, or a 243 political subdivision thereof, and non-commercial organizations 244 based in the US.) 246 - �C31/CC�: a foreign organization that regularly engages in 247 lawful activities (sales of goods or services or other 248 business, commercial, or non-commercial, including not for 249 profit relations) in the United States. The CC equals to the 250 country code of the organization, as defined in ISO 3166 [10]. 252 - �C32/CC� organization has an office or other facility in the 253 U.S., where CC equals to the county code of the organization, 254 as defined in ISO 3166 [10]. 256 C11 and C12 are sub-categories of Nexus Category 1. C21 is Nexus 257 Category 2. C31 and C32 are sub-categories of Nexus Category 3. 259 Note that the third sub-category of Nexus Category 1, i.e., �A 260 natural person whose primary place of domicile is in the US or any 261 of its possessions,� is not qualified to register domain names 262 under usTLD. 264 4. EPP Commands 266 Three EPP commands are involved in the exchange of usTLD 267 parameters between the registry and the registrars. They all apply 268 only to those contact objects that are to be used as registrants 269 for the usTLD domains. 271 - command. At the time of creating a contact 272 object for a registrant, usTLD parameters MUST be provided. 274 - command. It can be used to modify usTLD 275 parameters in a contact object that has already been created 276 for a usTLD registrant. 278 - command. It can be use to retrieve usTLD 279 parameters associated with a contact object for a usTLD 280 registrant. 282 Expires August 2002 5 283 New EPP Parameters for the usTLD February 2002 285 Regarding updating the usTLD parameters on a contact object using 286 , the following behaviors are assumed by the 287 registry: 289 - If no field, or only an empty field 290 such as or is present in 291 the command, no action is taken by the registry. That is, the 292 current value of either usTLD parameters, if exists, remain 293 unchanged. 295 - If either parameter is present in the field of the 296 command as a �parameter=value� pair and the value is not null, 297 e.g., 299 AppPurpose=P1 301 the registry will replace the value of the corresponding 302 parameter in the contact object with the value supplied in the 303 command. 305 - If either parameter is present in the field in the 306 command as a �parameter=value� pair and the value is null, 307 e.g., 309 AppPurpose= 311 the registry will remove the corresponding parameter from the 312 contact object. 314 - If either parameter does not appear in the field of 315 the command, the current value of the parameter, if exists, 316 remain unchanged. 318 Please refer to Section 5 for restrictions on update and removal of 319 usTLD parameters for a contact object as registrant of a usTLD 320 domain. 322 When a contact object is associated with a usTLD domain, three other 323 EPP commands corresponding to the domain object are also involved: 324 , and . Please see 325 Section 5 below. 327 5. Information Checking 329 The two new usTLD parameters defined in Section 3 only apply to 330 contact objects as registrants. Other contact objects, such as 331 administrative and billing contacts, do not REQUIRE the provision 332 of such information. 334 The intended usage of a contact object is identified when it is 335 associated with a domain object. The two usTLD parameters will be 336 checked by the registry server at the time when a contact object 337 is associated with a usTLD domain object as the registrant. 339 Sepcifically, when the contact object is associated with a domain 340 object as registrant in a or 341 command, if AppPurpose or NexusCategory does not exist for the 342 contact object, an EPP result code 2304 "Object status prohibits 343 operation" SHOULD be returned. Moreover, if the value of 345 Expires August 2002 6 346 New EPP Parameters for the usTLD February 2002 348 AppPurpose or NexusCategory is not valid, an EPP result code 2306 349 "Parameter value policy error" SHOULD be returned [3]. 351 Note that usTLD information checking for a contact object is done 352 only when it is associated with a domain name as registrant, not 353 at the time the contact object is created. It is the role of 354 registrant that stipulates the provision of the two usTLD 355 parameters for the contact object. 357 Once a contact object is associated with a registered usTLD domain 358 as registrant, both usTLD parameters MUST be present at all time. 359 A registrar MUST NOT use to remove either 360 parameters, otherwise an EPP result code 2304 "Object status 361 prohibits operation" SHOULD be returned. If the 362 command results in an invalid value for AppPurpose or 363 NexusCategory, an EPP result code 2306 "Parameter value policy 364 error" SHOULD be returned [3]. 366 6. Examples 368 The following are examples of the EPP extensions for the usTLD. 369 They are for illustrative purpose only. 371 Example 1: Creating a contact object: 373 C: 374 C: 378 C: 379 C: 380 C: 384 C: abcde 385 C: 386 C: abc 387 C: abc.org 388 C: 389 C: 123 d street 390 C: reston 391 C: 20194 392 C: VA 393 C: US 394 C: 395 C: 396 C: +1.2345678901 397 C: xxx@yyy.com 398 C: 123456 399 C: 400 C: 401 C: AppPurpose=P1 NexusCategory=C31/DE 402 C: coricopat-9978-1002 403 C: 404 C: 406 Expires August 2002 7 407 New EPP Parameters for the usTLD February 2002 409 Here the usTLD extensions convey that the registrant intends to 410 use the domain name for business purposes and the company is a 411 German company that has an office or other facility in the U.S. 413 Example 2: Updating information: 415 C: 416 C: 419 C: 420 C: 421 C: 425 C: abc 426 C: 427 C: +1.2345678910 428 C: 429 C: 430 C: 431 C: AppPurpose=P3 NexusCategory=C11 432 C: coricopat-28444-1005 433 C: 434 C: 436 This command will update the contact object with modifications as 437 follows: it�s intended for personal use and the registrant is a US 438 citizen. 440 Example 3: usTLD information in the response of . 442 S: 443 S: 447 S: 448 S: 449 S: Command completed successfully 450 S: 451 S: 452 S: 456 S: abcde 457 S: ABCDE-US 458 S: 459 S: 460 S: 461 S: abc 462 S: abc.org 463 S: 464 S: 123 d street 465 S: reston 466 S: 20194 467 S: VA 468 S: US 470 Expires August 2002 8 471 New EPP Parameters for the usTLD February 2002 473 S: 474 S: 475 S: +1.2345678901 476 S: xxx@yyy.com 477 S: ClientY 478 S: ClientX 479 S: 2002-04-03T22:00:00.0Z 480 S: ClientX 481 S: 2002-12-03T09:00:00.0Z 482 S: 2000-04-08T09:00:00.0Z 483 S: 123456 484 S: 485 S: 486 S: AppPurpose=P1 NexusCategory=C11 487 S: 488 S: coricopat-9978-1003 489 S: 54322-XYZ 490 S: 491 S: 492 S: 494 Here the Nexus information returned indicates that the registrant 495 registered the domain in .usTLD for business for profit and he/she 496 is an US citizen. The element may not be returned if 497 the querying registrar is not the sponsoring registrar. 499 7. Internationalization Considerations 501 The new parameters defined in this document are for usTLD only. 502 They do not introduce any additional international considerations 503 other than those specified for EPP contact object mapping [5]. 505 8. IANA Considerations 507 The new parameters defined in this document do not require IANA 508 registrations. 510 9. Security Considerations 512 The new parameters defined in this document do not provide any 513 other security services or introduce any additional considerations 514 beyond those described in EPP contact object mapping [5] 516 10. Acknowledgements 518 [TBD] 520 11. REFERENCES 522 [1] S. Bradner, "The Internet Standards Process -- Revision 3, 523 BCP9," RFC 2026, October 1996. 524 [2] S. Bradner, "Key Words for Use in RFCs to Indicate 525 Requirement Levels," RFC 2119, BCP 14, March 1997. 527 Expires August 2002 9 528 New EPP Parameters for the usTLD February 2002 530 [3] S. Hollenbeck, "Extensible Provisioning Protocol," Internet- 531 Draft draft-ietf-provreg-epp-06.txt, January 2002, Work in 532 Progress. 533 [4] S. Hollenbeck, "Extensible Provisioning Protocol Domain Name 534 Mapping," Internet-Draft draft-ietf-provreg-epp-domain- 535 04.txt, January 2002, Work in Progress. 536 [5] S. Hollenbeck, "Extensible Provisioning Protocol Contact 537 Mapping," Internet-Draft draft-ietf-provreg-epp-contact- 538 04.txt, January 2002, Work in Progress. 539 [6] S. Hollenbeck, "Extensible Provisioning Protocol Host 540 Mapping," Internet-Draft draft-ietf-provreg-epp-host-03.txt, 541 October 2001, Work in Progress. 542 [7] S. Hollenbeck, "Extensible Provisioning Protocol Transport 543 Over TCP," Internet-Draft draft-ietf-provreg-epp-tcp-04.txt, 544 January 2002, Work in Progress. 545 [8] A.Cooper and J. Postel, "The US Domain," RFC 1480, June 1993. 546 [9] NeuStar Inc, "The usTLD Nexus Requirements," 547 http://www.neustar.us/policies/docs/ustld_nexus_requirements. 548 pdf 549 [10] ISO 3166-1: "Codes for the representation of names of 550 countries and their subdivisions - Part 1: Country codes", 551 October 1997. http://www.din.de/gremien/nas/nabd/iso3166ma/ 553 12. Authors' Addresses 555 Hong Liu 556 NeuStar, Inc. 557 1120 Vermont Avenue, NW, Suite 550 558 Washington, D.C., 20005 559 U.S.A. 560 Email: hong.liu@neustar.biz 562 Ning Zhang 563 NeuStar, Inc 564 Loudoun Tech Center 565 45980 Center Oak Plaza 566 Sterling, VA 20166 567 U.S.A. 568 Phone: +1-571-434-5583 569 Email: ning.zhang@neustar.biz 571 Tom McGarry 572 NeuStar, Inc. 573 1120 Vermont Avenue, NW, Suite 550 574 Washington, D.C., 20005 575 U.S.A. 576 Phone: +1-202-533-2810 577 Email: tom.mcgarry@neustar.biz 579 Joseph Amsden 580 NeuStar, Inc 581 Loudoun Tech Center 582 45980 Center Oak Plaza 583 Sterling, VA 20166 584 U.S.A. 585 Phone: +1-571-434-5737 586 Email: joe.amsden@neustar.biz 588 Expires August 2002 10 589 New EPP Parameters for the usTLD February 2002 591 Ayesha Damaraju 592 NeuStar, Inc 593 Loudoun Tech Center 594 45980 Center Oak Plaza 595 Sterling, VA 20166 596 U.S.A. 597 Phone: +1-571-434-5581 598 Email: ayesha.damaraju@neustar.biz 600 Revisions From Previous Versions 602 Full Copyright Statement 604 "Copyright (C) The Internet Society (date). All Rights Reserved. 605 This document and translations of it may be copied and furnished 606 to others, and derivative works that comment on or otherwise 607 explain it or assist in its implementation may be prepared, 608 copied, published and distributed, in whole or in part, without 609 restriction of any kind, provided that the above copyright notice 610 and this paragraph are included on all such copies and derivative 611 works. However, this document itself may not be modified in any 612 way, such as by removing the copyright notice or references to the 613 Internet Society or other Internet organizations, except as needed 614 for the purpose of developing Internet standards in which case the 615 procedures for copyrights defined in the Internet Standards 616 process must be followed, or as required to translate it into. 618 Expires August 2002 11