Roger, Hopefully others will weigh in on the list and these should be topics for the REGEXT working session.
I believe what is defined in the 01 draft is a new option, which could be called Option D. My perspective is that Option C is too heavy weight for an extension to the check command, but I conceded my objection previously. Option D makes Option C look light, where the availability check morphs into a fee info of many domains and operations, with availability as a side note. If Option D is the direction that this draft is moving, I highly recommend that we either create a new verb (e.g., fee check) like the claims check defined in the Claims Check Form of draft-ietf-regext-launchphase or we bring back the extension of the info command and response. On the server-side the fee extension would be handled separately and merged with the availability check information, which is better suited as separate operations. On the location of the “avail” attribute, the 01 draft does not properly support the handling of an invalid domain name. What should the server do if the client passes an invalid domain name, return “avail=false” for each of the commands? I much prefer fast-failing returning the fee information for a domain name that is invalid, bocked, or reserved by returning “avail=false” at the object level and not returning any of the command elements. I view having some sort of standardization of fee classifications with extensibility as being an important element for making the extension more meaningful to clients and servers. I also view the expected server behavior for the availability check values (if we continue to extend the availability check command) and the handling of billable operations of premium domain names as an important topic for discussion and hopefully defining in the draft. I look forward to other thoughts on this and I look forward to an effective REGEXT working session on this. — JG [cid:image001.png@01D2997F.66B092F0] James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://verisigninc.com/> From: regext <regext-boun...@ietf.org> on behalf of Roger Carney <rcar...@godaddy.com> Date: Wednesday, March 8, 2017 at 4:52 PM To: "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-epp-fees-01.txt Good Afternoon, Thanks for the review and comments James!!! I think your discussion of Option C is a great starting point for the list. I believe, this current version 01 allows for more flexibility/refinement (being able to request different fees for different domains) then what you describe. Obviously there is more cost with this flexibility, more defining, validating, etc. I am open to either solution and would like to see what the others think about the “flexibility” need and use of the current draft 01 versus what you are proposing. And likewise on your discussion of the location of the “avail” attribute, I think the current version 01 allows for more flexibility/refinement. Again, I am open to either solution and would like to hear what others think. As for your number items: 1. Fixed in version 02 (coming soon) 2. I think this is left open and could potentially be extended. 3. a) I will work to include descriptions in version 03. I don’t think we want to state the default period as 1 year, I think that should be left to server policy; b) I agree that this should be directed by server policy and will update wording in version 03; c) As mentioned above “avail” at the command level provides more flexibility/refinement; d) “avail” defaults to 1. 4. I agree and will look for missing definitions, please pass along any that you see are missing. 5. I think the create should fail if the passed in fee does not match the server fee. 6. I think it should return available if it is available. 7. Good question. I like the idea of some predefined with extensibility. Again, I think this version was built for flexibility but I think we need to consider the complexity and use and balance correctly, please share your thoughts. Thanks Roger -----Original Message----- From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Gould, James Sent: Monday, March 06, 2017 2:26 PM To: regext@ietf.org Subject: Re: [regext] I-D Action: draft-ietf-regext-epp-fees-01.txt 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<mailto: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<mailto:internet-dra...@ietf.org>" <regext-boun...@ietf.org on behalf of internet-dra...@ietf.org<mailto:regext-boun...@ietf.org%20on%20behalf%20of%20internet-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<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
