James, This will meet our needs. Thanks for whipping that up real quick. My only concern would be with 2.d. Although I know of no TLD that has a model without a standard fee, I can imagine one. I worry that it might provide too much freedom and be abused in the case where there is a de facto standard class, but it is named something other then standard, which would defeat the purpose of the standard fee attribute. I guess the chances of that happening could be mitigated using verbiage in the draft though, and I definitely prefer this remote chance to not having the standard fee attribute.
Thanks again, -Pat On Thu, Nov 16, 2017 at 4:39 PM Gould, James <jgo...@verisign.com> wrote: > 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 > > > [image: image001.png] > > > > > *James Gould *Distinguished Engineer > jgo...@verisign.com > > 703-948-3271 <(703)%20948-3271> > 12061 Bluemont Way > <https://maps.google.com/?q=12061+Bluemont+Way+%0D+Reston,+VA+20190&entry=gmail&source=g> > Reston, VA 20190 > <https://maps.google.com/?q=12061+Bluemont+Way+%0D+Reston,+VA+20190&entry=gmail&source=g> > > 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> 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 > <https://maps.google.com/?q=12061+Bluemont+Way+%0D+Reston,+VA+20190&entry=gmail&source=g> > Reston, VA 20190 > <https://maps.google.com/?q=12061+Bluemont+Way+%0D+Reston,+VA+20190&entry=gmail&source=g> > > 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 <(720)%20663-0025> > -- -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
