In review of draft-ietf-regext-epp-fees-01, I have the following feedback.
From a high-level, I believe that draft-ietf-regext-epp-fees-01 does not match the target of Option C presented by Gavin Brown at IETF-97 (https://www.ietf.org/proceedings/95/slides/slides-95-regext-9.pdf ), which consists of an extension to the domain names in the body of the <check> command with a list of commands in the extension. All the domains in the body would get the fee information for the same set of commands included in the fee extension. I believe that the response “avail” attribute needs to be included in the cd element and not in the command sub-element, so that it’s an all of nothing result per domain name. This way invalid or reserved domain names would return “avail=0” in the cd element without inclusion of a command sub-elements. I included full command and response examples for the Option B and Option C discussed at IETF 97 in the mail posting https://www.ietf.org/mail-archive/web/eppext/current/msg00883.html. 1. Section 1.1 since refer to “0.13” instead of “0.1” 2. Section 3.1 “Client Commands” a. Can you extend the supported commands? For example, can we add the command “sync” for the consolidate command? There is no enumerated list in the XSD, but the text in 3.1 states “The list of values include:”. Does this allow only using these command strings or can we define new ones? 3. Section 5.1.1 “EPP <check> Command” a. Add a description for the <fee:period> and <fee:class> elements that includes their meaning in relationship to the extension to the check command. i. I assume that not specifying the period matches the period that is defined for the object mapping. In the case of a domain name, the default period would be 1 year for the create, renew, and transfer commands. The restore would not support a period, since it is a fixed fee, so there are commands where the period would not be allowed. b. The number of supported <fee:command> elements would be up to server policy, since I don’t believe we would support specifying every billable command and every possible period within a single extension to a check command. That sort of bulk query is best suited for an extension to the info command as in a fee info command, which was removed in one of the prior versions of the draft. c. Why are you putting the “avail” attribute at the <fee:command> level instead of the <fee:cd> level? What if the domain name is invalid or there is some other input issue like the currency is invalid? The server would want to fast fail on the entire object and not at the command level. If the “avail” flag is at the command level, then it is best suited to look to extend info instead of the check command, since this is getting much to heavy weight for a check command and response. d. The response sample does not include an “avail” attribute for each of the <fee:command> elements. 4. I believe we should define the fields of the responses under each of the commands or reference out to a section that defines them. 5. Should a create fail if the client does not pass a fee that is greater than or equal to the premium domain name fee? We don’t define what a “premium” domain name is or any expected behavior if a client does not provide the extension. Should we define such expected server behavior in the draft? 6. Should a premium domain name be returned as unavailable in the check if the fee extension is not passed, since the create would most likely fail later in the purchase flow? We don’t define what a “premium” domain name is or any expected behavior if the client does not provide the fee extension. 7. Should there be an enumerated list of <fee:class> values with some form of extensibility? Section 3.7 “Classification of Objects” predefines the “standard” classification. Should we predefine some additional classifications that have generic meaning to both the client and the server? For example, you could predefine an enumerated list including “premium”, “standard”, and “discount” with some form of customization like the use of the enumerated “custom” value with an optional “name” attribute to specify the custom name or custom sub-classification. If we had predefined classification values with predefined meanings, we could define expected (MAY, SHOULD, or MUST) behavior for the handling of different classifications. — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com <http://verisigninc.com/> On 3/3/17, 5:13 PM, "regext on behalf of internet-dra...@ietf.org" <regext-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Registration Protocols Extensions of the IETF. Title : Registry Fee Extension for the Extensible Provisioning Protocol (EPP) Authors : Roger Carney Gavin Brown Jothan Frakes Filename : draft-ietf-regext-epp-fees-01.txt Pages : 34 Date : 2017-03-03 Abstract: This document describes an Extensible Provisioning Protocol (EPP) extension mapping for registry fees. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-regext-epp-fees-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-fees-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
