--- 1/draft-ietf-regext-epp-fees-16.txt 2019-09-06 14:13:04.282383837 -0700 +++ 2/draft-ietf-regext-epp-fees-17.txt 2019-09-06 14:13:04.350385581 -0700 @@ -1,20 +1,20 @@ Registration Protocols Extensions R. Carney Internet-Draft GoDaddy Inc. Intended status: Standards Track G. Brown -Expires: November 2, 2019 CentralNic Group plc +Expires: March 8, 2020 CentralNic Group plc J. Frakes - May 1, 2019 + September 5, 2019 Registry Fee Extension for the Extensible Provisioning Protocol (EPP) - draft-ietf-regext-epp-fees-16 + draft-ietf-regext-epp-fees-17 Abstract Given the expansion of the DNS namespace, and the proliferation of novel business models, it is desirable to provide a method for Extensible Provisioning Protocol (EPP) clients to query EPP servers for the fees and credits and provide expected fees and credits for certain commands and objects. This document describes an EPP extension mapping for registry fees. @@ -26,21 +26,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 2, 2019. + This Internet-Draft will expire on March 8, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -78,42 +78,43 @@ 5.2.1. EPP Command . . . . . . . . . . . . . . . . 18 5.2.2. EPP Command . . . . . . . . . . . . . . . . 20 5.2.3. EPP Command . . . . . . . . . . . . . . . . . 21 5.2.4. EPP Command . . . . . . . . . . . . . . . 23 5.2.5. EPP Command . . . . . . . . . . . . . . . . 25 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1. Fee Extension Schema . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 8.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 32 - 8.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 33 + 8.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 32 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 33 - 9.1. RegistryEngine EPP Service . . . . . . . . . . . . . . . 34 + 9.1. RegistryEngine EPP Service . . . . . . . . . . . . . . . 33 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 - 11. Change History . . . . . . . . . . . . . . . . . . . . . . . 35 - 11.1. Change from 15 to 16 . . . . . . . . . . . . . . . . . . 35 - 11.2. Change from 14 to 15 . . . . . . . . . . . . . . . . . . 35 - 11.3. Change from 13 to 14 . . . . . . . . . . . . . . . . . . 35 - 11.4. Change from 12 to 13 . . . . . . . . . . . . . . . . . . 35 - 11.5. Change from 11 to 12 . . . . . . . . . . . . . . . . . . 35 - 11.6. Change from 10 to 11 . . . . . . . . . . . . . . . . . . 35 - 11.7. Change from 09 to 10 . . . . . . . . . . . . . . . . . . 35 - 11.8. Change from 08 to 09 . . . . . . . . . . . . . . . . . . 36 - 11.9. Change from 07 to 08 . . . . . . . . . . . . . . . . . . 36 - 11.10. Change from 06 to 07 . . . . . . . . . . . . . . . . . . 36 - 11.11. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 36 - 11.12. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 36 - 11.13. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 36 - 11.14. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 37 - 11.15. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 37 - 11.16. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 37 - 11.17. Change from draft-brown-00 to draft-ietf-regext-fees-00 37 + 11. Change History . . . . . . . . . . . . . . . . . . . . . . . 34 + 11.1. Change from 16 to 17 . . . . . . . . . . . . . . . . . . 34 + 11.2. Change from 15 to 16 . . . . . . . . . . . . . . . . . . 34 + 11.3. Change from 14 to 15 . . . . . . . . . . . . . . . . . . 35 + 11.4. Change from 13 to 14 . . . . . . . . . . . . . . . . . . 35 + 11.5. Change from 12 to 13 . . . . . . . . . . . . . . . . . . 35 + 11.6. Change from 11 to 12 . . . . . . . . . . . . . . . . . . 35 + 11.7. Change from 10 to 11 . . . . . . . . . . . . . . . . . . 35 + 11.8. Change from 09 to 10 . . . . . . . . . . . . . . . . . . 35 + 11.9. Change from 08 to 09 . . . . . . . . . . . . . . . . . . 35 + 11.10. Change from 07 to 08 . . . . . . . . . . . . . . . . . . 36 + 11.11. Change from 06 to 07 . . . . . . . . . . . . . . . . . . 36 + 11.12. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 36 + 11.13. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 36 + 11.14. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 36 + 11.15. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 36 + 11.16. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 37 + 11.17. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 37 + 11.18. Change from draft-brown-00 to draft-ietf-regext-fees-00 37 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 12.1. Normative References . . . . . . . . . . . . . . . . . . 37 12.2. Informative References . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction Historically, domain name registries have applied a simple fee structure for billable transactions, namely a basic unit price applied to domain , , and RGP [RFC3915] @@ -151,23 +152,20 @@ MUST NOT depend on it and instead employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents. In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in examples are provided only to illustrate element relationships and are not a required feature of this protocol. 2. Migrating to Newer Versions of This Extension - (Note to RFC Editor: remove this section before publication as an - RFC.) - Servers which implement this extension SHOULD provide a way for clients to progressively update their implementations when a new version of the extension is deployed. Servers SHOULD (for a temporary migration period) provide support for older versions of the extension in parallel to the newest version, and allow clients to select their preferred version via the element of the command. If a client requests multiple versions of the extension at login, @@ -205,25 +203,25 @@ The element MAY have an OPTIONAL "phase" attribute specifying a launch phase as described in [RFC8334]. It may also contain an OPTIONAL "subphase" attribute identifying the custom or sub-phase as described in [RFC8334]. 3.2. Currency Codes The element is used to indicate which currency fees are charged in. This value of this element MUST be a three-character - currency code from [ISO4217]. + currency code from [ISO4217:2015]. - Note that ISO 4217 provides the special "XXX" code, which MAY be used - if the server uses a non-currency based system for assessing fees, - such as a system of credits. + Note that ISO 4217:2015 provides the special "XXX" code, which MAY be + used if the server uses a non-currency based system for assessing + fees, such as a system of credits. The use of elements in client commands is OPTIONAL: if a element is not present in a command, the server MUST determine the currency based on the server default currency or based on the client's account settings which are agreed to by the client and server via an out-of-band channel. However, the element MUST be present in responses. Servers SHOULD NOT perform a currency conversion if a client uses an incorrect currency code. Servers SHOULD return a 2004 "Parameter @@ -238,28 +236,31 @@ element described in [RFC5731]. The element is OPTIONAL in commands, if omitted, the server MUST determine the fee(s) using the server default period. The element MUST be present in responses. 3.4. Fees and Credits Servers which implement this extension will include elements in responses which provide information about the fees and/or credits - associated with a given billable transaction. + associated with a given billable transaction. A fee will result in + subtracting from the Account Balance (described in Section 3.5) and a + credit will result in adding to the Account Balance (described in + Section 3.5). The and elements are used to provide this information. The presence of a element in a response indicates a debit against the client's account balance; a element indicates a credit. A element MUST - have a non-negative value. A element MUST have a - negative value. + have a zero or non-negative value. A element MUST have + a zero or negative value. A server MAY respond with multiple and elements in the same response. In such cases, the net fee or credit applicable to the transaction is the arithmetic sum of the values of each of the and/or elements. This amount applies to the total additional validity period applied to the object (where applicable) rather than to any incremental unit. The following attributes are defined for the element. These are described in detail below: @@ -1166,59 +1167,34 @@ One schema is presented here that is the EPP Fee Extension schema. The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The BEGIN and END tags are not part of the schema; they are used to note the beginning and ending of the schema for URI registration purposes. 6.1. Fee Extension Schema - Copyright (c) 2018 IETF Trust and the persons identified as authors - of the code. All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - o Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - o Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - o Neither the name of Internet Society, IETF or IETF Trust, nor the - names of specific contributors, may be used to endorse or promote - products derived from this software without specific prior written - permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + The formal syntax presented here is a complete schema representation + of the object mapping suitable for automated validation of EPP XML + instances. The BEGIN and END tags are not part of the schema; they + are used to note the beginning and ending of the schema for URI + registration purposes. BEGIN - Extensible Provisioning Protocol v1.0 Fee Extension @@ -1408,21 +1384,25 @@ END 7. Security Considerations The mapping extensions described in this document do not provide any security services beyond those described by EPP [RFC5730], the EPP domain name mapping [RFC5731], and protocol layers used by EPP. The security considerations described in these other specifications apply - to this specification as well. + to this specification as well. This extension passes financial + information using the EPP protocol, so confidentiality and integrity + protection must be provided by the transport mechanism. All + transports compliant with [RFC5730] provide the needed level of + confidentiality and integrity protections. 8. IANA Considerations 8.1. XML Namespace This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. Registration request for the fee namespace: @@ -1520,154 +1499,160 @@ o Seth Goldman of Google o Klaus Malorny and Michael Bauland of Knipp o Jody Kolker, Joe Snitker and Kevin Allendorf of Go Daddy o Michael Holloway of Com Laude o Santosh Kalsangrah of Impetus Infotech o Alex Mayrhofer of Nic.at o Thomas Corte of Knipp Medien und Kommunikation GmbH 11. Change History -11.1. Change from 15 to 16 +11.1. Change from 16 to 17 + + Updated per AD review, all updates were just textual for clarity and + correctness. + +11.2. Change from 15 to 16 Updated per AD review and list comments: several grammar corrections; clarification text added to section 3.4.3 and 3.5; and a schema update for consistency by providing a "lang" attribute to the and "description" attribute detailed in section 3.4. -11.2. Change from 14 to 15 +11.3. Change from 14 to 15 Updated schema, moving the "standard" attribute of the "commandDataType" inside the block. -11.3. Change from 13 to 14 +11.4. Change from 13 to 14 Moved RFC 7451 reference from Normative to Informative section. -11.4. Change from 12 to 13 +11.5. Change from 12 to 13 Updated XML namespace and schema registration to be "epp" scoped - global replace of XML namespace from urn:ietf:params:xml:ns:fee-1.0 to urn:ietf:params:xml:ns:epp:fee-1.0 and the XML schema registration from urn:ietf:params:xml:schema:fee-1.0 to urn:ietf:params:xml:schema:epp:fee-1.0. -11.5. Change from 11 to 12 +11.6. Change from 11 to 12 Updated references to current version of documents and moved the "standard" attribute from the check command (commandType) to the check response (commandDataType). -11.6. Change from 10 to 11 +11.7. Change from 10 to 11 Updated document per Working Group Last Call comments. Made minor textual changes throughout for enhanced clarity per WGLC comments. -11.7. Change from 09 to 10 +11.8. Change from 09 to 10 Updated document per Working Group Last Call comments. Updated schema to version 1.0 in anticipation of standardization, no changes were made to the latest, 0.25, schema. Made minor textual changes throughout for enhanced clarity per WGLC comments. -11.8. Change from 08 to 09 +11.9. Change from 08 to 09 Updated scheme to version 0.25 to allow tighter checking on by splitting the client and server definitions, moved the class element from the command to the object level and added an optional standard attribute to the command element. Also updated section 3.1 for clarity on name attribute; updated section 3.9 for clarity on uses of ; removed second paragraph in section 5.2.1 as it was duplicative of second to last paragraph in 4.0; and updated section 5.1.1 to add section references. -11.9. Change from 07 to 08 +11.10. Change from 07 to 08 Updated section 3.8 and 5.1.1 to provide clarity on server processing and response of various scenarios (i.e. "quiet" period processing). -11.10. Change from 06 to 07 +11.11. Change from 06 to 07 Updated section 3.8 and 4.0 to provide clarity on server processing and response of various scenarios. -11.11. Change from 05 to 06 +11.12. Change from 05 to 06 Updated scheme to version 0.23 to allow the return of no element(s) if an error situation occurs. Edited section 3.8 extensively after input from interim meeting and REGEXT F2F meeting at IETF-99. Added normative reference for draft-ietf- eppext-launchphase. -11.12. Change from 04 to 05 +11.13. Change from 04 to 05 Updated scheme to version 0.21 to support the lang attribute for the reason element of the objectCDType and the commandType types as well as to add the update command to the commandEnum type. Updated section 3.1 to include language for the custom command. Added section 3.9 to provide a description of the element. Fixed typos and added clarification text on when client fee is less than server fee in section 4. Additionally, I added description pointers to appropriate Section 3 definitions for element clarity throughout the document. -11.13. Change from 03 to 04 +11.14. Change from 03 to 04 Updated scheme to version 0.19 to correct typos and to replace the commandTypeValue type with the commandEnum type and customName attribute for stricter validation. Updated various text for grammar and clarity. Added text to section 4 clarifying the response when the client provided no fee extension but the server was expecting the extension. -11.14. Change from 02 to 03 +11.15. Change from 02 to 03 Updated scheme to version 0.17 to simplify the check command syntax. Moved fee avail to objectCDType to allow fast failing on error situations. Removed the objectCheckType as it was no longer being used. Updated examples to reflect these scheme changes. Added language for server failing a if the passed by the client is less than the server fee. -11.15. Change from 01 to 02 +11.16. Change from 01 to 02 Updated scheme to version 0.15 to fix errors in CommandType, objectCDType, transformCommandType and transformResultType definitions. -11.16. Change from 00 to 01 +11.17. Change from 00 to 01 Added Roger Carney as author to finish draft. Moved Formal Syntax section to main level numbering. Various grammar, typos, and administrative edits for clarity. Removed default value for the "applied" attribute of so that it can truly be optional. Added support for the command to return a element as well. Modified default response on the command for the optional when it was not provided in the command, leaving it to the server to provide the default period value. Extensive edits were done to the command, the response and to the fee extension schema (checkType, objectCheckType, objectIdentifierType, objectCDType, commandType) to support requesting and returning multiple transformation fees in a single call. Added section on Phase/Subphase to provide more context on the uses. -11.17. Change from draft-brown-00 to draft-ietf-regext-fees-00 +11.18. Change from draft-brown-00 to draft-ietf-regext-fees-00 Updated to be REGEXT WG document. 12. References 12.1. Normative References - [ISO4217] International Organization for Standardization, "Codes for + [ISO4217:2015] + International Organization for Standardization, "Codes for the representation of currencies", August 2015, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004,