Pat, In thinking about it a little bit, how about the following proposal that I believe will address both of our concerns.
1. To meet the definition of the classification, move the <fee:class> element up from the <fee:command> element to the <fee:cd> element. a. This will clearly make the optional classification an object-level attribute in the check response. b. This will provide a hint to the client of the validity of the fee schedule for the object, where the “standard” classification fee schedule should be well known and more stable than a “non-standard” classification fee schedule. 2. Add a new optional “standard” boolean attribute to the <fee:command> element, with the default value of “0” (or “false”), that indicates whether the fees for the command and period matches the “standard” classification fees for the command and period. a. I believe this would match your use case of a “non-standard” classification domain name, where the create command fee is different from the “standard” classification fee (standard=”0” or undefined) and where the renew command fee is the same as the “standard” classification fee (standard=”1”). b. All of the <fee:command> elements for a “standard” classification domain name, would have standard=”1”. c. This requires the server to compare the “non-standard” classification fee schedule for each specified command against the “standard” classification fee schedule to set the appropriate “standard” attribute. d. There is no assumption that there is a “standard” fee schedule for the TLD, which would mean that the “standard” classification (<fee:class>) would not be specified and the “standard” attribute would be set to “0” or not set for all commands. Thoughts? — JG [id:image001.png@01D255E2.EB933A30] James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Pat Moroney <pmoro...@name.com> Date: Friday, November 17, 2017 at 1:36 AM To: James Gould <jgo...@verisign.com> Cc: Andreas Huber <ahu...@united-domains.de>, "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] REGEXT Fee Document James, We are not advocating the classification at the period level. Adding the class to the command level doesn't require the server to be any more complex. It can internally keep the same model where the object has a classification and thus each command has the same classification. But, with this extra freedom, the server can then decide to offer more detailed information such as standard renewals on objects with non-standard creates, which is becoming a more common model. The class element came about when I suggested having a boolean flag for standard vs non-standard fees. If I remember correctly, Jens Wagner suggested extending it to allow a tier name. Registries currently use different tiers for different commands, and limiting it to a per-object classification would restrict their ability to market and price these domains. Since the current draft leaves it up to the server operator to define the non-standard classes out of band, I would assume it would be up to them what would happen in your "gold" vs "silver" example. To address Andreas's suggestion to omit standard fees: we prefer all fees be transmitted. This has prevented issues in the past when the standard rates change. Out of band transmission of fees is prone to manual error, and those errors can be costly. Thanks, -Pat Moroney On Thu, Nov 16, 2017 at 2:32 AM Gould, James <jgo...@verisign.com<mailto:jgo...@verisign.com>> wrote: Andreas, The point of the fee extension is to return the actual fee values, with the option of including a classification as a hint to the client of the fee schedule being used for the object (domain). There is no concept of a “standard” or “non-standard” fee, but a “standard” or “non-standard” object (domain). What classifications (one, both, or none) would be returned for a renew if there were two “non-standard” classifications (e.g., “gold” and “silver”) with the same renew fee that does not match the “standard” renew fee? There is not a single fee for a command, but a fee for the combination of the command and the supported periods. Defining a classification at the command and period level adds a whole new level of confusion and complexity for the client and the server. Maybe the concept of fee classification in general is too vague where there is no one fee classification data model on the server-side and there is certainly not a single fee processing model on the client-side to come up with a standard definition and protocol to support it. — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271<tel:(703)%20948-3271> 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 11/16/17, 4:16 PM, "regext on behalf of Andreas Huber" <regext-boun...@ietf.org<mailto:regext-boun...@ietf.org> on behalf of ahu...@united-domains.de<mailto:ahu...@united-domains.de>> wrote: Hi all, <fee:class> should be under <fee:command>. I have the same points than Pat. We do not need to know if a price of a single command *COULD* be non-standard. Thats the same as completely skipping <fee:class>. Indeed, what I really need, is to know if a single fee is "standard" or "non-standard" priced, because we do a completely different processing of premium and standard (or promotion) fees. While registries had premium fees for create, renew and transfer, this wasn't a big thing, but since most registries switch to premium create with standard renew fees, we need to differentiate. So, I would suggest to clarify section 3.7 and change it to fee level. To save some bytes in the check response, <fee:class> with "standard" could be assumed as default and therefore optional, but mandatory if non-standard (premium, promotion, etc.). Another solution would be to not transmit standard fees in the fee extension at all. Thanks, Andreas Am 16.11.2017 um 04:44 schrieb Gould, James: > Pat, > > > > I will go back to the definition of the classification, which is an object-level attribute (e.g., “standard” or “premium” domain). Each classification has a fee schedule (commands and periods) that is assigned at the object-level, where the combination of the command and the period has a fee and not a classification. The classification (<fee:class>) should be placed in the location that reflects the definition to remove any confusion, which is under the <fee:cd> element. > > > > — > > > _______________________________________________ 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 -- -Pat Moroney Sr. Software Engineer Name.com http://www.youtube.com/watch?v=V1GKGXXF12c 720-663-0025
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
