idnits 2.17.1 draft-ietf-regext-epp-fees-19.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 (October 11, 2019) is 1659 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) == Missing Reference: 'RFC5646' is mentioned on line 448, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Registration Protocols Extensions R. Carney 3 Internet-Draft GoDaddy Inc. 4 Intended status: Standards Track G. Brown 5 Expires: April 13, 2020 CentralNic Group plc 6 J. Frakes 7 October 11, 2019 9 Registry Fee Extension for the Extensible Provisioning Protocol (EPP) 10 draft-ietf-regext-epp-fees-19 12 Abstract 14 Given the expansion of the DNS namespace, and the proliferation of 15 novel business models, it is desirable to provide a method for 16 Extensible Provisioning Protocol (EPP) clients to query EPP servers 17 for the fees and credits and provide expected fees and credits for 18 certain commands and objects. This document describes an EPP 19 extension mapping for registry fees. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 13, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 57 2. Migrating to Newer Versions of This Extension . . . . . . . . 4 58 3. Extension Elements . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Client Commands . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Currency Codes . . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Validity Periods . . . . . . . . . . . . . . . . . . . . 5 62 3.4. Fees and Credits . . . . . . . . . . . . . . . . . . . . 6 63 3.4.1. Refunds . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.4.2. Grace Periods . . . . . . . . . . . . . . . . . . . . 7 65 3.4.3. Correlation between Refundability and Grace Periods . 7 66 3.4.4. Applicability . . . . . . . . . . . . . . . . . . . . 7 67 3.5. Account Balance . . . . . . . . . . . . . . . . . . . . . 8 68 3.6. Credit Limit . . . . . . . . . . . . . . . . . . . . . . 8 69 3.7. Classification of Objects . . . . . . . . . . . . . . . . 9 70 3.8. Phase and Subphase Attributes . . . . . . . . . . . . . . 9 71 3.9. Reason . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4. Server Handling of Fee Information . . . . . . . . . . . . . 11 73 5. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 12 74 5.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 12 75 5.1.1. EPP Command . . . . . . . . . . . . . . . . . 12 76 5.1.2. EPP Transfer Query Command . . . . . . . . . . . . . 16 77 5.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 18 78 5.2.1. EPP Command . . . . . . . . . . . . . . . . 18 79 5.2.2. EPP Command . . . . . . . . . . . . . . . . 20 80 5.2.3. EPP Command . . . . . . . . . . . . . . . . . 21 81 5.2.4. EPP Command . . . . . . . . . . . . . . . 23 82 5.2.5. EPP Command . . . . . . . . . . . . . . . . 25 83 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 27 84 6.1. Fee Extension Schema . . . . . . . . . . . . . . . . . . 27 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 87 8.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 32 88 8.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 32 89 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 33 90 9.1. RegistryEngine EPP Service . . . . . . . . . . . . . . . 33 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 92 11. Change History . . . . . . . . . . . . . . . . . . . . . . . 34 93 11.1. Change from 18 to 19 . . . . . . . . . . . . . . . . . . 34 94 11.2. Change from 17 to 18 . . . . . . . . . . . . . . . . . . 34 95 11.3. Change from 16 to 17 . . . . . . . . . . . . . . . . . . 34 96 11.4. Change from 15 to 16 . . . . . . . . . . . . . . . . . . 35 97 11.5. Change from 14 to 15 . . . . . . . . . . . . . . . . . . 35 98 11.6. Change from 13 to 14 . . . . . . . . . . . . . . . . . . 35 99 11.7. Change from 12 to 13 . . . . . . . . . . . . . . . . . . 35 100 11.8. Change from 11 to 12 . . . . . . . . . . . . . . . . . . 35 101 11.9. Change from 10 to 11 . . . . . . . . . . . . . . . . . . 35 102 11.10. Change from 09 to 10 . . . . . . . . . . . . . . . . . . 35 103 11.11. Change from 08 to 09 . . . . . . . . . . . . . . . . . . 35 104 11.12. Change from 07 to 08 . . . . . . . . . . . . . . . . . . 36 105 11.13. Change from 06 to 07 . . . . . . . . . . . . . . . . . . 36 106 11.14. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 36 107 11.15. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 36 108 11.16. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 36 109 11.17. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 37 110 11.18. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 37 111 11.19. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 37 112 11.20. Change from draft-brown-00 to draft-ietf-regext-fees-00 37 113 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 114 12.1. Normative References . . . . . . . . . . . . . . . . . . 37 115 12.2. Informative References . . . . . . . . . . . . . . . . . 38 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 118 1. Introduction 120 Historically, domain name registries have applied a simple fee 121 structure for billable transactions, namely a basic unit price 122 applied to domain , , and RGP [RFC3915] 123 restore commands. Given the relatively small number of EPP servers 124 to which EPP clients have been required to connect, it has generally 125 been the case that client operators have been able to obtain details 126 of these fees out-of-band by contacting the server operators. 128 Given the expansion of the DNS namespace, and the proliferation of 129 novel business models, it is desirable to provide a method for EPP 130 clients to query EPP servers for the fees and credits associated with 131 certain commands and specific objects. 133 This document describes an extension mapping for version 1.0 of the 134 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping 135 provides a mechanism by which EPP clients may query the fees and 136 credits associated with various billable transactions, and obtain 137 their current account balance. 139 1.1. Conventions Used in This Document 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 XML is case sensitive. Unless stated otherwise, XML specifications 148 and examples provided in this document MUST be interpreted in the 149 character case presented in order to develop a conforming 150 implementation. 152 "fee" is used as an abbreviation for "urn:ietf:params:xml:ns:epp:fee- 153 1.0". The XML namespace prefix "fee" is used, but implementations 154 MUST NOT depend on it and instead employ a proper namespace-aware XML 155 parser and serializer to interpret and output the XML documents. 157 In examples, "C:" represents lines sent by a protocol client and "S:" 158 represents lines returned by a protocol server. Indentation and 159 white space in examples are provided only to illustrate element 160 relationships and are not a required feature of this protocol. 162 2. Migrating to Newer Versions of This Extension 164 Servers which implement this extension SHOULD provide a way for 165 clients to progressively update their implementations when a new 166 version of the extension is deployed. 168 Servers SHOULD (for a temporary migration period) provide support for 169 older versions of the extension in parallel to the newest version, 170 and allow clients to select their preferred version via the 171 element of the command. 173 If a client requests multiple versions of the extension at login, 174 then, when preparing responses to commands which do not include 175 extension elements, the server SHOULD only include extension elements 176 in the namespace of the newest version of the extension requested by 177 the client. 179 When preparing responses to commands which do include extension 180 elements, the server SHOULD only include extension elements for the 181 extension versions present in the command. 183 3. Extension Elements 185 3.1. Client Commands 187 The element is used in the EPP command to 188 determine the fee that is applicable to the given command. 190 The use of the keys off the use of the "name" attribute 191 to define which transform fees the client is requesting information 192 about. Here is the list of possible values for the "name" attribute: 194 o "create" indicating a command as defined in [RFC5730]; 195 o "delete" indicating a command as defined in [RFC5730]; 196 o "renew" indicating a command as defined in [RFC5730]; 197 o "update" indicating a command as defined in [RFC5730]; 198 o "transfer" indicating a command as defined in 199 [RFC5730]; 200 o If the server supports the Registry Grace Period Mapping 201 [RFC3915], then the server MUST also support the "restore" value 202 as defined in [RFC3915]; 203 o "custom" indicating a custom command that MUST set the 204 "customName" attribute with custom command name. The possible set 205 of custom command name values is up to server policy. 207 The element MAY have an OPTIONAL "phase" attribute 208 specifying a launch phase as described in [RFC8334]. It may also 209 contain an OPTIONAL "subphase" attribute identifying the custom or 210 sub-phase as described in [RFC8334]. 212 3.2. Currency Codes 214 The element is used to indicate which currency fees 215 are charged in. This value of this element MUST be a three-character 216 currency code from [ISO4217:2015]. 218 Note that ISO 4217:2015 provides the special "XXX" code, which MAY be 219 used if the server uses a non-currency based system for assessing 220 fees, such as a system of credits. 222 The use of elements in client commands is OPTIONAL: if 223 a element is not present in a command, the server MUST 224 determine the currency based on the server default currency or based 225 on the client's account settings which are agreed to by the client 226 and server via an out-of-band channel. However, the 227 element MUST be present in responses. 229 Servers SHOULD NOT perform a currency conversion if a client uses an 230 incorrect currency code. Servers SHOULD return a 2004 "Parameter 231 value range" error instead. 233 3.3. Validity Periods 235 When querying for fee information using the command, the 236 element is used to indicate the period measured in years 237 or months, with the appropriate units specified using the "unit" 238 attribute to be added to the registration period of objects by the 239 , and commands. This element is derived 240 from the element described in [RFC5731]. 242 The element is OPTIONAL in commands, if omitted, 243 the server MUST determine the fee(s) using the server default period. 244 The element MUST be present in responses. 246 3.4. Fees and Credits 248 Servers which implement this extension will include elements in 249 responses which provide information about the fees and/or credits 250 associated with a given billable transaction. A fee will result in 251 subtracting from the Account Balance (described in Section 3.5) and a 252 credit will result in adding to the Account Balance (described in 253 Section 3.5). 255 The and elements are used to provide this 256 information. The presence of a element in a response 257 indicates a debit against the client's account balance; a 258 element indicates a credit. A element MUST 259 have a zero or greater (non-negative) value. A element 260 MUST have a negative value. 262 A server MAY respond with multiple and 263 elements in the same response. In such cases, the net fee or credit 264 applicable to the transaction is the arithmetic sum of the values of 265 each of the and/or elements. This amount 266 applies to the total additional validity period applied to the object 267 (where applicable). 269 The following attributes are defined for the element. 270 These are described in detail below: 272 description: an OPTIONAL attribute which provides a human-readable 273 description of the fee. Servers should provide documentation on the 274 possible values of this attribute, and their meanings. An OPTIONAL 275 "lang" attribute MAY be present, per the language structure in 276 [RFC5646], to identify the language of the returned text and has a 277 default value of "en" (English). If the "description" attribute is 278 not present, the "lang" attribute can be ignored. 280 refundable: an OPTIONAL boolean attribute indicating whether the fee 281 is refundable if the object is deleted. 283 grace-period: an OPTIONAL attribute which provides the time period 284 during which the fee is refundable. 286 applied: an OPTIONAL attribute indicating when the fee will be 287 deducted from the client's account. 289 The element can take a "description" attribute as 290 described above. An OPTIONAL "lang" attribute MAY be present to 291 identify the language of the returned text and has a default value of 292 "en" (English). 294 3.4.1. Refunds 296 elements MAY have an OPTIONAL "refundable" attribute which 297 takes a boolean value. Fees may be refunded under certain 298 circumstances, such as when a domain application is rejected (as 299 described in [RFC8334]) or when an object is deleted during the 300 relevant Grace Period (see below). 302 If the "refundable" attribute is omitted, then clients SHOULD NOT 303 make any assumption about the refundability of the fee. 305 3.4.2. Grace Periods 307 [RFC3915] describes a system of "grace periods", which are time 308 periods following a billable transaction during which, if an object 309 is deleted, the client receives a refund. 311 The "grace-period" attribute MAY be used to indicate the relevant 312 grace period for a fee. If a server implements the Registry Grace 313 Period extension [RFC3915], it MUST specify the grace period for all 314 relevant transactions. 316 If the "grace-period" attribute is omitted, then clients SHOULD NOT 317 make any assumption about the grace period of the fee. 319 3.4.3. Correlation between Refundability and Grace Periods 321 If a element has a "grace-period" attribute then it MUST 322 also be refundable and the "refundable" attribute MUST be true. If 323 the "refundable" attribute of a element is false then it 324 MUST NOT have a "grace-period" attribute. 326 3.4.4. Applicability 328 Fees may be applied immediately upon receipt of a command from a 329 client, or may only be applied once an out-of-band process (such as 330 the processing of applications at the end of a launch phase) has 331 taken place. 333 The "applied" attribute of the element allows servers to 334 indicate whether a fee will be applied immediately, or whether it 335 will be applied at some point in the future. This attribute takes 336 two possible values: "immediate" or "delayed". 338 3.5. Account Balance 340 The element is an OPTIONAL element which MAY be 341 included in server responses to transform commands. If present, it 342 can be used by the client to determine the remaining credit at the 343 server. 345 Whether or not the is included in responses is a matter 346 of server policy. However, if a server chooses to offer support for 347 this element, it MUST be included in responses to all "transform" or 348 billable commands (e.g. , , , , 349 ). 351 The value of the MAY be negative. A negative balance 352 indicates that the server has extended a line of credit to the client 353 (see below). 355 If a server includes a element in response to transform 356 commands, the value of the element MUST reflect the client's account 357 balance after any fees or credits associated with that command have 358 been applied. If the "applied" attribute of the element is 359 "delayed", then the MUST reflect the client's account 360 balance without any fees or credits associated with that command. 362 3.6. Credit Limit 364 As described above, if a server returns a response containing a 365 with a negative value, then the server has extended a 366 line of credit to the client. A server MAY also include a 367 element in responses that indicates the maximum 368 credit available to a client. A server MAY reject certain 369 transactions if the absolute value of the is equal to 370 or exceeds the value of the element. 372 Whether or not the is included in responses is a 373 matter of server policy. However, if a server chooses to offer 374 support for this element, it MUST be included in responses to all 375 "transform" commands (e.g. , , , , 376 ). 378 3.7. Classification of Objects 380 Objects may be assigned to a particular class, category, or tier, 381 each of which has a particular fee or set of fees associated with it. 382 The element, which MAY appear in and transform 383 responses, is used to indicate the classification of an object. 385 If a server makes use of this element, it should provide clients with 386 a list of all the values that the element may take via an out-of-band 387 channel. Servers MUST NOT use values which do not appear on this 388 list. 390 Servers that make use of this element MUST use a element 391 with the value "standard" for all objects that are subject to the 392 standard or default fee. 394 3.8. Phase and Subphase Attributes 396 The element has two attributes, phase and subphase, 397 that provide additional information related to a specific launch 398 phase as described in [RFC8334]. These attributes are used as 399 filters that should refine the server processing. 401 If the client contains a server supported combination 402 of phase/subphase the server MUST return fee data (including the 403 phase/subphase attribute(s)) for the specific combination. 405 If the client contains no phase/subphase attributes and 406 the server has only one active phase/subphase combination the server 407 MUST return data (including the phase/subphase attribute(s)) of the 408 currently active phase/subphase. 410 If the client contains no phase/subphase attributes and 411 the server has more than one active phase/subphase combination the 412 server MUST respond with a 2003 "Required parameter missing" error. 414 If the client contains no phase/subphase attributes and 415 the server is currently in a "quiet period" (e.g. not accepting 416 registrations or applications) the server MUST return data consistent 417 with the default general availability phase (e.g. "open" or "claims") 418 including the appropriate phase/subphase attribute(s). 420 If the client contains a phase attribute with no 421 subphase and the server has only one active subphase (or no subphase) 422 of this phase, the server MUST return data (including the phase/ 423 subphase attribute(s)) of the provided phase and currently active 424 subphase. 426 If the client contains a phase attribute with no 427 subphase and the server has more than one active subphase combination 428 of this phase, the server MUST respond with a 2003 "Required 429 parameter missing" error. 431 If the client contains a subphase with no phase 432 attribute the server MUST respond with a 2003 "Required parameter 433 missing" error. 435 If the client contains a phase attribute not defined in 436 [RFC8334] or not supported by server the server MUST respond with a 437 2004 "Parameter value range" error. 439 If the client contains a subphase attribute (or phase/ 440 subphase combination) not supported by server the server MUST respond 441 with a 2004 "Parameter value range" error. 443 3.9. Reason 445 The element is used to provide server specific text in 446 an effort to better explain why a command did not complete as 447 the client expected. An OPTIONAL "lang" attribute MAY be present to 448 identify the language, per the language structure in [RFC5646], of 449 the returned text and has a default value of "en" (English). 451 The element can be used within the server response 452 element or within the element. See section 453 5.1.1 for details on the "check data" element. 455 If the server cannot calculate the relevant fees, because the object, 456 command, currency, period, class or some combination is invalid per 457 server policy, the server has two ways of handling error processing 458 of element(s): 460 1. Fast-fail - The server, upon error identification, MAY stop 461 processing elements and return to the client a 462 containing the and a element 463 detailing the reason for failure. 465 S: 466 S: example.xyz 467 S: Only 1 year registration periods are 468 S: valid. 469 S: 471 2. Partial-fail - The server, upon error identification, MAY 472 continue processing elements and return to the 473 client a containing successfully processed 474 elements and failed elements. All returned failed 475 elements MUST have a element detailing 476 the reason for failure, and the server MAY additionally include a 477 element at the level. 479 S: 480 S: example.xyz 481 S: 482 S: 2 483 S: Only 1 year registration periods are 484 S: valid. 485 S: 486 S: 488 In either failure scenario the server MUST set the avail 489 attribute to false (0) and the server MUST process all objects in the 490 client request. 492 4. Server Handling of Fee Information 494 Depending on server policy, a client MAY be required to include the 495 extension elements described in this document for certain transform 496 commands. Servers must provide clear documentation to clients about 497 the circumstances in which this extension must be used. 499 The server MUST return avail="0" in its response to a command 500 for any object in the command that does not include the 501 extension for which the server would likewise fail a 502 domain command when no extension is provided for that 503 same object. 505 If a server receives a command from a client, which results 506 in no possible fee combination, the server MUST set the "avail" 507 attribute of the element to false (0) and provide a 508 . 510 If a server receives a command from a client, which results 511 in an ambiguous result (i.e. multiple possible fee combinations) the 512 server MUST reject the command with a 2003 "Required parameter 513 missing" error. 515 If a server receives a command from a client, which does not include 516 the fee extension data elements required by the server for that 517 command, then the server MUST respond with a 2003 "Required parameter 518 missing" error. 520 If the total fee provided by the client is less than the server's own 521 calculation of the fee or the server determines the currency is 522 inappropriate for that command, then the server MUST reject the 523 command with a 2004 "Parameter value range" error. 525 5. EPP Command Mapping 527 A detailed description of the EPP syntax and semantics can be found 528 in [RFC5730]. 530 5.1. EPP Query Commands 532 This extension does not add any elements to the EPP or 533 commands or responses. 535 5.1.1. EPP Command 537 This extension defines a new command called the Fee Check Command 538 that defines additional elements for the EPP command to 539 provide fee information along with the availability information of 540 the EPP command. 542 The command MAY contain an element which MAY contain a 543 element. The element MAY contain one 544 element and MUST contain one or more 545 elements. 547 The element(s) MUST contain(s) a "name" attribute (see 548 Section 3.1), an OPTIONAL "phase" attribute, and an OPTIONAL 549 "subphase" attribute (see Section 3.8). The element(s) 550 MAY have the following child elements: 552 o An OPTIONAL element (as described in Section 3.3). 554 Example command: 556 C: 557 C: 558 C: 559 C: 560 C: 562 C: example.com 563 C: example.net 564 C: example.xyz 565 C: 566 C: 567 C: 568 C: 569 C: USD 570 C: 571 C: 2 572 C: 573 C: 574 C: 575 C: 576 C: 577 C: 578 C: ABC-12345 579 C: 580 C: 582 When the server receives a command that includes the 583 extension elements described above, its response MUST contain an 584 element, which MUST contain a child 585 element. The element MUST contain a 586 element and a element for each object referenced in the 587 client command. 589 Each (check data) element MUST contain the following child 590 elements: 592 o A element, which MUST match an element referenced in 593 the client command. 594 o An OPTIONAL element (as described in Section 3.7). 595 o A element matching each (unless the 596 "avail" attribute of the if false) that appeared in the 597 corresponding of the client command. This element MAY 598 have the OPTIONAL "standard" attribute, with a default value of 599 "0" (or "false"), which indicates whether the fee matches the fee 600 of the "standard" classification (see section 3.7). This element 601 MAY have the OPTIONAL "phase" and "subphase" attributes, which 602 will match the same attributes in the corresponding 603 element of the client command if sent by the client. 605 The element also has an OPTIONAL "avail" attribute which is 606 a boolean. If the value of this attribute evaluates to false, this 607 indicates that the server cannot calculate the relevant fees, because 608 the object, command, currency, period, class or some combination is 609 invalid per server policy. If "avail" is false then the or 610 the element MUST contain a element (as 611 described in Section 3.9) and the server MAY eliminate some or all of 612 the element(s). 614 The element(s) MAY have the following child elements: 616 o An OPTIONAL element (as described in Section 3.3), 617 which contains the same unit, if present, that appeared in the 618 element of the command. If the value of the parent 619 element is "restore", this element MUST NOT be 620 included, otherwise it MUST be included. If no 621 appeared in the client command (and the command is not "restore") 622 then the server MUST return its default period value. 623 o Zero or more elements (as described in Section 3.4). 624 o Zero or more elements (as described in Section 3.4). 625 o An OPTIONAL element (as described in Section 3.9). 627 If the "avail" attribute of the element is true (1) and if 628 no elements are present in a element, this 629 indicates that no fee will be assessed by the server for this 630 command. 632 If the "avail" attribute of the element is true (1), then 633 the element MUST NOT contain a element. 635 Example response: 637 S: 638 S: 639 S: 640 S: 641 S: Command completed successfully 642 S: 643 S: 644 S: 646 S: 647 S: example.com 648 S: 649 S: 650 S: example.net 651 S: 652 S: 653 S: example.xyz 654 S: 655 S: 656 S: 657 S: 658 S: 660 S: USD 661 S: 662 S: example.com 663 S: Premium 664 S: 665 S: 2 666 S: 10.00 670 S: 671 S: 672 S: 1 673 S: 10.00 677 S: 678 S: 679 S: 1 680 S: 10.00 684 S: 685 S: 686 S: 15.00 688 S: 689 S: 690 S: 691 S: example.net 692 S: standard 693 S: 694 S: 2 695 S: 5.00 699 S: 700 S: 701 S: 1 702 S: 5.00 706 S: 707 S: 708 S: 1 709 S: 5.00 713 S: 714 S: 715 S: 5.00 717 S: 718 S: 719 S: 720 S: example.xyz 721 S: 722 S: 2 723 S: Only 1 year registration periods are 724 S: valid. 725 S: 726 S: 727 S: 728 S: 729 S: 730 S: ABC-12345 731 S: 54322-XYZ 732 S: 733 S: 734 S: 736 5.1.2. EPP Transfer Query Command 738 This extension does not add any elements to the EPP query 739 command, but does include elements in the response, when the 740 extension is included in the command service extensions. 742 When the query command has been processed successfully, if 743 the client has included the extension in the command service 744 element, and if the client is authorized by the server 745 to view information about the transfer, then the server MAY include 746 in the section of the EPP response a 747 element, which contains the following child elements: 749 o A element (as described in Section 3.2). 750 o A element (as described in Section 3.3). 751 o Zero or more elements (as described in Section 3.4) 752 containing the fees that will be charged to the gaining client. 753 o Zero or more elements (as described in Section 3.4) 754 containing the credits that will be refunded to the losing client. 756 Servers SHOULD omit when returning a response to the 757 gaining client, and omit elements when returning a response 758 to the losing client. 760 If no element is included in the response, then no fee 761 will be assessed by the server for the transfer. 763 Example query response: 765 S: 766 S: 767 S: 768 S: 769 S: Command completed successfully; action pending 770 S: 771 S: 772 S: 774 S: example.com 775 S: pending 776 S: ClientX 777 S: 2019-06-08T22:00:00.0Z 778 S: ClientY 779 S: 2019-06-13T22:00:00.0Z 780 S: 2021-09-08T22:00:00.0Z 781 S: 782 S: 783 S: 784 S: 785 S: USD 786 S: 1 787 S: 5.00 788 S: 789 S: 790 S: 791 S: ABC-12345 792 S: 54322-XYZ 793 S: 794 S: 795 S: 797 5.2. EPP Transform Commands 799 5.2.1. EPP Command 801 This extension adds elements to both the EPP command and 802 response, when the extension is included in the command 803 service extensions. 805 When submitting a command to the server, the client MAY 806 include in the element a element which 807 includes the following child elements: 809 o An OPTIONAL element (as described in Section 3.2); 810 o One or more elements (as described in Section 3.4). 812 When the command has been processed successfully, and the 813 client included the extension in the command service 814 extensions, and a fee was assessed by the server for the transaction, 815 the server MUST include in the section of the EPP 816 response a element, which contains the following child 817 elements: 819 o A element (as described in Section 3.2); 820 o Zero or more elements (as described in Section 3.4); 821 o Zero or more elements (as described in Section 3.4); 822 o An OPTIONAL element (as described in Section 3.5); 823 o An OPTIONAL element (as described in 824 Section 3.6). 826 Example command: 828 C: 829 C: 830 C: 831 C: 832 C: 834 C: example.com 835 C: 2 836 C: 837 C: ns1.example.net 838 C: ns2.example.net 839 C: 840 C: jd1234 841 C: sh8013 842 C: sh8013 843 C: 844 C: 2fooBAR 845 C: 846 C: 847 C: 848 C: 849 C: 850 C: USD 851 C: 5.00 852 C: 853 C: 854 C: ABC-12345 855 C: 856 C: 857 Example response: 859 S: 860 S: 861 S: 862 S: 863 S: Command completed successfully 864 S: 865 S: 866 S: 868 S: example.com 869 S: 2019-04-03T22:00:00.0Z 870 S: 2021-04-03T22:00:00.0Z 871 S: 872 S: 873 S: 874 S: 875 S: USD 876 S: 5.00 881 S: -5.00 882 S: 1000.00 883 S: 884 S: 885 S: 886 S: ABC-12345 887 S: 54321-XYZ 888 S: 889 S: 890 S: 892 5.2.2. EPP Command 894 This extension does not add any elements to the EPP command, 895 but does include elements in the response, when the extension is 896 included in the command service extensions. 898 When the command has been processed successfully, and the 899 client included the extension in the command service 900 extensions, the server MAY include in the section of the 901 EPP response a element, which contains the following 902 child elements: 904 o A element (as described in Section 3.2); 905 o Zero or more elements (as described in Section 3.4); 906 o Zero or more elements (as described in Section 3.4); 907 o An OPTIONAL element (as described in Section 3.5); 908 o An OPTIONAL element (as described in 909 Section 3.6). 911 Example response: 913 S: 914 S: 915 S: 916 S: 917 S: Command completed successfully 918 S: 919 S: 920 S: 922 S: USD 923 S: -5.00 926 S: 1005.00 927 S: 928 S: 929 S: 930 S: ABC-12345 931 S: 54321-XYZ 932 S: 933 S: 934 S: 936 5.2.3. EPP Command 938 This extension adds elements to both the EPP command and 939 response, when the extension is included in the command 940 service extensions. 942 When submitting a command to the server, the client MAY 943 include in the element a element which 944 includes the following child elements: 946 o An OPTIONAL element (as described in Section 3.2); 947 o One or more elements (as described in Section 3.4). 949 When the command has been processed successfully, and the 950 client included the extension in the command service 951 extensions, the server MAY include in the section of the 952 EPP response a element, which contains the following 953 child elements: 955 o A element (as described in Section 3.2); 956 o Zero or more elements (as described in Section 3.4); 957 o Zero or more elements (as described in Section 3.4); 958 o An OPTIONAL element (as described in Section 3.5); 959 o An OPTIONAL element (as described in 960 Section 3.6). 962 Example command: 964 C: 965 C: 966 C: 967 C: 968 C: 970 C: example.com 971 C: 2019-04-03 972 C: 5 973 C: 974 C: 975 C: 976 C: 977 C: USD 978 C: 5.00 979 C: 980 C: 981 C: ABC-12345 982 C: 983 C: 984 Example response: 986 S: 987 S: 988 S: 989 S: 990 S: Command completed successfully 991 S: 992 S: 993 S: 995 S: example.com 996 S: 2024-04-03T22:00:00.0Z 997 S: 998 S: 999 S: 1000 S: 1001 S: USD 1002 S: 5.00 1005 S: 1000.00 1006 S: 1007 S: 1008 S: 1009 S: ABC-12345 1010 S: 54322-XYZ 1011 S: 1012 S: 1013 S: 1015 5.2.4. EPP Command 1017 This extension adds elements to both the EPP command and 1018 response, when the value of the "op" attribute of the 1019 command element is "request", and the extension is included in the 1020 command service extensions. 1022 When submitting a command to the server, the client MAY 1023 include in the element a element which 1024 includes the following child elements: 1026 o An OPTIONAL element (as described in Section 3.2); 1027 o One or more elements (as described in Section 3.4). 1029 When the command has been processed successfully, and the 1030 client included the extension in the command service 1031 extensions, the server MAY include in the section of the 1032 EPP response a element, which contains the following 1033 child elements: 1035 o A element (as described in Section 3.2); 1036 o Zero or more elements (as described in Section 3.4); 1037 o Zero or more elements (as described in Section 3.4); 1038 o An OPTIONAL element (as described in Section 3.5); 1039 o An OPTIONAL element (as described in 1040 Section 3.6). 1042 Example command: 1044 C: 1045 C: 1046 C: 1047 C: 1048 C: 1050 C: example.com 1051 C: 1 1052 C: 1053 C: 2fooBAR 1054 C: 1055 C: 1056 C: 1057 C: 1058 C: 1059 C: USD 1060 C: 5.00 1061 C: 1062 C: 1063 C: ABC-12345 1064 C: 1065 C: 1066 Example response: 1068 S: 1069 S: 1070 S: 1071 S: 1072 S: Command completed successfully; action pending 1073 S: 1074 S: 1075 S: 1077 S: example.com 1078 S: pending 1079 S: ClientX 1080 S: 2019-06-08T22:00:00.0Z 1081 S: ClientY 1082 S: 2019-06-13T22:00:00.0Z 1083 S: 2021-09-08T22:00:00.0Z 1084 S: 1085 S: 1086 S: 1087 S: 1088 S: USD 1089 S: 5.00 1092 S: 1093 S: 1094 S: 1095 S: ABC-12345 1096 S: 54322-XYZ 1097 S: 1098 S: 1099 S: 1101 5.2.5. EPP Command 1103 This extension adds elements to both the EPP command and 1104 response, when the extension is included in the command 1105 service extensions. 1107 When submitting a command to the server, the client MAY 1108 include in the element a element which 1109 includes the following child elements: 1111 o An OPTIONAL element (as described in Section 3.2); 1112 o One or more elements (as described in Section 3.4). 1114 When the command has been processed successfully, and the 1115 client included the extension in the command service 1116 extensions, the server MAY include in the section of the 1117 EPP response a element, which contains the following 1118 child elements: 1120 o A element (as described in Section 3.2); 1121 o Zero or more elements (as described in Section 3.4); 1122 o Zero or more elements (as described in Section 3.4); 1123 o An OPTIONAL element (as described in Section 3.5); 1124 o An OPTIONAL element (as described in 1125 Section 3.6). 1127 Example command: 1129 C: 1130 C: 1131 C: 1132 C: 1133 C: 1135 C: example.com 1136 C: 1137 C: sh8013 1138 C: 1139 C: 1140 C: 1141 C: 1142 C: 1143 C: USD 1144 C: 5.00 1145 C: 1146 C: 1147 C: ABC-12345 1148 C: 1149 C: 1150 Example response: 1152 S: 1153 S: 1154 S: 1155 S: 1156 S: Command completed successfully 1157 S: 1158 S: 1159 S: 1160 S: USD 1161 S: 5.00 1162 S: 1163 S: 1164 S: 1165 S: ABC-12345 1166 S: 54321-XYZ 1167 S: 1168 S: 1169 S: 1171 6. Formal Syntax 1173 One schema is presented here that is the EPP Fee Extension schema. 1175 The formal syntax presented here is a complete schema representation 1176 of the object mapping suitable for automated validation of EPP XML 1177 instances. The BEGIN and END tags are not part of the schema; they 1178 are used to note the beginning and ending of the schema for URI 1179 registration purposes. 1181 6.1. Fee Extension Schema 1183 The formal syntax presented here is a complete schema representation 1184 of the object mapping suitable for automated validation of EPP XML 1185 instances. The BEGIN and END tags are not part of the schema; they 1186 are used to note the beginning and ending of the schema for URI 1187 registration purposes. 1189 BEGIN 1190 1191 1197 1198 1200 1201 1202 Extensible Provisioning Protocol v1.0 Fee Extension 1203 1204 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1219 1220 1221 1222 1224 1226 1227 1229 1230 1231 1232 1234 1235 1236 1238 1239 1240 1241 1242 1244 1246 1248 1249 1250 1251 1252 1254 1255 1256 1257 1259 1260 1261 1262 1264 1266 1268 1269 1271 1272 1273 1274 1276 1278 1280 1282 1284 1286 1287 1289 1290 1291 1292 1293 1295 1297 1298 1299 1301 1302 1303 1304 1305 1306 1308 1309 1310 1311 1312 1314 1316 1318 1319 1320 1321 1322 1324 1325 1326 1327 1328 1329 1330 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1349 1350 1351 1352 1353 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1374 1375 1376 1377 1378 1379 1380 1381 1383 1384 1385 1387 1388 1389 1391 1392 END 1394 7. Security Considerations 1396 The mapping extensions described in this document do not provide any 1397 security services beyond those described by EPP [RFC5730], the EPP 1398 domain name mapping [RFC5731], and protocol layers used by EPP. The 1399 security considerations described in these other specifications apply 1400 to this specification as well. This extension passes financial 1401 information using the EPP protocol, so confidentiality and integrity 1402 protection must be provided by the transport mechanism. All 1403 transports compliant with [RFC5730] provide the needed level of 1404 confidentiality and integrity protections. The server will only 1405 provide information, including financial information, that is 1406 relevant to the authenticated client. 1408 8. IANA Considerations 1410 8.1. XML Namespace 1412 This document uses URNs to describe XML namespaces and XML schemas 1413 conforming to a registry mechanism described in [RFC3688]. 1415 Registration request for the fee namespace: 1417 URI: urn:ietf:params:xml:ns:epp:fee-1.0 1419 Registrant Contact: IESG 1421 XML: None. Namespace URIs do not represent an XML specification. 1423 Registration request for the fee schema: 1425 URI: urn:ietf:params:xml:schema:epp:fee-1.0 1427 Registrant Contact: IESG 1429 XML: See the "Formal Syntax" section of this document. 1431 8.2. EPP Extension Registry 1433 The EPP extension described in this document should be registered by 1434 the IANA in the EPP Extension Registry described in [RFC7451]. The 1435 details of the registration are as follows: 1437 Name of Extension: Registry Fee Extension for the Extensible 1438 Provisioning Protocol (EPP) 1439 Document status: Standards Track 1441 Reference: (insert reference to RFC version of this document) 1443 Registrant Name and Email Address: IESG, 1445 TLDs: Any 1447 IPR Disclosure: None 1449 Status: Active 1451 Notes: None 1453 9. Implementation Status 1455 Note to RFC Editor: Please remove this section and the reference to 1456 [RFC7942] before publication. 1458 This section records the status of known implementations of the 1459 protocol defined by this specification at the time of posting of this 1460 Internet-Draft, and is based on a proposal described in [RFC7942]. 1461 The description of implementations in this section is intended to 1462 assist the IETF in its decision processes in progressing drafts to 1463 RFCs. Please note that the listing of any individual implementation 1464 here does not imply endorsement by the IETF. Furthermore, no effort 1465 has been spent to verify the information presented here that was 1466 supplied by IETF contributors. This is not intended as, and must not 1467 be construed to be, a catalog of available implementations or their 1468 features. Readers are advised to note that other implementations may 1469 exist. 1471 According to [RFC7942], "this will allow reviewers and working groups 1472 to assign due consideration to documents that have the benefit of 1473 running code, which may serve as evidence of valuable experimentation 1474 and feedback that have made the implemented protocols more mature. 1475 It is up to the individual working groups to use this information as 1476 they see fit". 1478 9.1. RegistryEngine EPP Service 1480 Organization: CentralNic 1482 Name: RegistryEngine EPP Service 1484 Description: Generic high-volume EPP service for gTLDs, ccTLDs and 1485 SLDs 1486 Level of maturity: Deployed in CentralNic's production environment as 1487 well as two other gTLD registry systems, and two ccTLD registry 1488 systems. 1490 Coverage: All aspects of the protocol are implemented. 1492 Licensing: Proprietary In-House software 1494 Contact: epp@centralnic.com 1496 URL: https://www.centralnic.com 1498 10. Acknowledgements 1500 The authors wish to thank the following persons for their feedback 1501 and suggestions: 1503 o James Gould of Verisign Inc 1504 o Luis Munoz of ISC 1505 o Michael Young of Architelos 1506 o Ben Levac and Jeff Eckhaus of Demand Media 1507 o Seth Goldman of Google 1508 o Klaus Malorny and Michael Bauland of Knipp 1509 o Jody Kolker, Joe Snitker and Kevin Allendorf of Go Daddy 1510 o Michael Holloway of Com Laude 1511 o Santosh Kalsangrah of Impetus Infotech 1512 o Alex Mayrhofer of Nic.at 1513 o Thomas Corte of Knipp Medien und Kommunikation GmbH 1515 11. Change History 1517 11.1. Change from 18 to 19 1519 Updated per IESG review, all updates (except for one schema change) 1520 were just textual for clarity and correctness. The schema change was 1521 to require the name attribute of the commandType element. 1523 11.2. Change from 17 to 18 1525 Corrected erroneous edit left in place in previous revision (17), 1526 reverted text back to original text (revision 16) in section 3.4. 1528 11.3. Change from 16 to 17 1530 Updated per AD review, all updates were just textual for clarity and 1531 correctness. 1533 11.4. Change from 15 to 16 1535 Updated per AD review and list comments: several grammar corrections; 1536 clarification text added to section 3.4.3 and 3.5; and a schema 1537 update for consistency by providing a "lang" attribute to the 1538 and "description" attribute detailed in 1539 section 3.4. 1541 11.5. Change from 14 to 15 1543 Updated schema, moving the "standard" attribute of the 1544 "commandDataType" inside the block. 1546 11.6. Change from 13 to 14 1548 Moved RFC 7451 reference from Normative to Informative section. 1550 11.7. Change from 12 to 13 1552 Updated XML namespace and schema registration to be "epp" scoped - 1553 global replace of XML namespace from urn:ietf:params:xml:ns:fee-1.0 1554 to urn:ietf:params:xml:ns:epp:fee-1.0 and the XML schema registration 1555 from urn:ietf:params:xml:schema:fee-1.0 to 1556 urn:ietf:params:xml:schema:epp:fee-1.0. 1558 11.8. Change from 11 to 12 1560 Updated references to current version of documents and moved the 1561 "standard" attribute from the check command (commandType) to the 1562 check response (commandDataType). 1564 11.9. Change from 10 to 11 1566 Updated document per Working Group Last Call comments. Made minor 1567 textual changes throughout for enhanced clarity per WGLC comments. 1569 11.10. Change from 09 to 10 1571 Updated document per Working Group Last Call comments. Updated 1572 schema to version 1.0 in anticipation of standardization, no changes 1573 were made to the latest, 0.25, schema. Made minor textual changes 1574 throughout for enhanced clarity per WGLC comments. 1576 11.11. Change from 08 to 09 1578 Updated scheme to version 0.25 to allow tighter checking on 1579 by splitting the client and server definitions, moved 1580 the class element from the command to the object level and added an 1581 optional standard attribute to the command element. Also updated 1582 section 3.1 for clarity on name attribute; updated section 3.9 for 1583 clarity on uses of ; removed second paragraph in section 1584 5.2.1 as it was duplicative of second to last paragraph in 4.0; and 1585 updated section 5.1.1 to add section references. 1587 11.12. Change from 07 to 08 1589 Updated section 3.8 and 5.1.1 to provide clarity on server processing 1590 and response of various scenarios (i.e. "quiet" period processing). 1592 11.13. Change from 06 to 07 1594 Updated section 3.8 and 4.0 to provide clarity on server processing 1595 and response of various scenarios. 1597 11.14. Change from 05 to 06 1599 Updated scheme to version 0.23 to allow the return of no 1600 element(s) if an error situation occurs. Edited 1601 section 3.8 extensively after input from interim meeting and REGEXT 1602 F2F meeting at IETF-99. Added normative reference for draft-ietf- 1603 eppext-launchphase. 1605 11.15. Change from 04 to 05 1607 Updated scheme to version 0.21 to support the lang attribute for the 1608 reason element of the objectCDType and the commandType types as well 1609 as to add the update command to the commandEnum type. Updated 1610 section 3.1 to include language for the custom command. Added 1611 section 3.9 to provide a description of the element. 1612 Fixed typos and added clarification text on when client fee is less 1613 than server fee in section 4. Additionally, I added description 1614 pointers to appropriate Section 3 definitions for element clarity 1615 throughout the document. 1617 11.16. Change from 03 to 04 1619 Updated scheme to version 0.19 to correct typos and to replace the 1620 commandTypeValue type with the commandEnum type and customName 1621 attribute for stricter validation. Updated various text for grammar 1622 and clarity. Added text to section 4 clarifying the response 1623 when the client provided no fee extension but the server was 1624 expecting the extension. 1626 11.17. Change from 02 to 03 1628 Updated scheme to version 0.17 to simplify the check command syntax. 1629 Moved fee avail to objectCDType to allow fast failing on error 1630 situations. Removed the objectCheckType as it was no longer being 1631 used. Updated examples to reflect these scheme changes. Added 1632 language for server failing a if the passed by the 1633 client is less than the server fee. 1635 11.18. Change from 01 to 02 1637 Updated scheme to version 0.15 to fix errors in CommandType, 1638 objectCDType, transformCommandType and transformResultType 1639 definitions. 1641 11.19. Change from 00 to 01 1643 Added Roger Carney as author to finish draft. Moved Formal Syntax 1644 section to main level numbering. Various grammar, typos, and 1645 administrative edits for clarity. Removed default value for the 1646 "applied" attribute of so that it can truly be optional. 1647 Added support for the command to return a element 1648 as well. Modified default response on the command for the 1649 optional when it was not provided in the command, 1650 leaving it to the server to provide the default period value. 1651 Extensive edits were done to the command, the 1652 response and to the fee extension schema (checkType, objectCheckType, 1653 objectIdentifierType, objectCDType, commandType) to support 1654 requesting and returning multiple transformation fees in a single 1655 call. Added section on Phase/Subphase to provide more context on the 1656 uses. 1658 11.20. Change from draft-brown-00 to draft-ietf-regext-fees-00 1660 Updated to be REGEXT WG document. 1662 12. References 1664 12.1. Normative References 1666 [ISO4217:2015] 1667 International Organization for Standardization, "Codes for 1668 the representation of currencies", August 2015, 1669 . 1671 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1672 Requirement Levels", BCP 14, RFC 2119, 1673 DOI 10.17487/RFC2119, March 1997, 1674 . 1676 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1677 DOI 10.17487/RFC3688, January 2004, 1678 . 1680 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 1681 the Extensible Provisioning Protocol (EPP)", RFC 3915, 1682 DOI 10.17487/RFC3915, September 2004, 1683 . 1685 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1686 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1687 . 1689 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1690 Domain Name Mapping", STD 69, RFC 5731, 1691 DOI 10.17487/RFC5731, August 2009, 1692 . 1694 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1695 Code: The Implementation Status Section", BCP 205, 1696 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1697 . 1699 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1700 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1701 May 2017, . 1703 [RFC8334] Gould, J., Tan, W., and G. Brown, "Launch Phase Mapping 1704 for the Extensible Provisioning Protocol (EPP)", RFC 8334, 1705 DOI 10.17487/RFC8334, March 2018, 1706 . 1708 12.2. Informative References 1710 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 1711 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 1712 February 2015, . 1714 Authors' Addresses 1715 Roger Carney 1716 GoDaddy Inc. 1717 14455 N. Hayden Rd. #219 1718 Scottsdale, AZ 85260 1719 US 1721 Email: rcarney@godaddy.com 1722 URI: http://www.godaddy.com 1724 Gavin Brown 1725 CentralNic Group plc 1726 35-39 Moorgate 1727 London, England EC2R 6AR 1728 GB 1730 Phone: +44 20 33 88 0600 1731 Email: gavin.brown@centralnic.com 1732 URI: http://www.centralnic.com 1734 Jothan Frakes 1736 Email: jothan@jothan.com 1737 URI: http://jothan.com