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> 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 <(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 on behalf of 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 > https://www.ietf.org/mailman/listinfo/regext > > > _______________________________________________ > regext mailing list > 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
