Hi, I agree that the classification is an object-level attribute. I see your perspective of not requiring the registry fee extension if the fee for a non-standard domain is the same as the standard fee, but the registrars would need to implement to approach that will work with registries that would be to always pass the fee in billable commands for non-standard domains. In the draft the only language associated with the requirement to pass the extension is for the create command (If a <create> command is received with no <fee:create> extension and the server requires a <fee:create> extension for the <domain:name> the server MUST respond with a 2003 "Required parameter missing" error). There is no similar language around the requirement for the fee extension for the other billable commands (renew, transfer, extended update for commands like sync and restore). This comes down to how much server policy or constraints gets injected into the protocol.
Should the registry fee extension be supplied for all billable commands for a non-standard classification domain, or should the registry fee extension be supplied for all billable commands with a non-standard fee, or should the registry fee extension be supplied for all billable commands? An additional question is how to handle billable commands for clients that have not implemented the registry fee extension. If you desire consistency in server implementations and simplicity in the client implementations, there needs to be agreement on this. If the decision is “the registry fee extension MUST be supplied for all billable commands for a non-standard classification domain”, then that means that the classification alone drives the expected interface. If the decision is “the registry fee extension MUST be supplied for all billable commands with a non-standard fee”, then that means that the classification provides a hint but that the client needs to know which fees are non-standard. If the decision is “the registry fee extension MUST be supplied for all billable commands” then the classification is simply information to the client along with any command-level attributes. I believe that a non-standard fee schedule may be more volatile than the standard fee schedule, so although at a point in time a fee may be the same as the standard fee, I would prefer “the registry fee extension MUST be supplied for all billable commands for a non-standard classification domain” to address clients that don’t support the registry fee extension and address the volatility risk of a non-standard fee schedule. I agree that adding the <fee:command> “standard” attribute adds complexity on the server. If a default value is provided in the XML schema, then it really is not optional, since a value will be implied if it’s not explicitly provided. Therefore, servers will indicate whether the fee is “standard” or not explicitly or implicitly. If a fee-level fee (standard or non-standard) does impact the interface for a subsequent billable command, then the server should provide it. The decision on how to handle non-standard objects and fees will help drive whether both the classification and command-level “standard” flag is required in the protocol. — 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: Alexander Mayrhofer <alexander.mayrho...@nic.at> Date: Wednesday, November 22, 2017 at 9:10 AM To: James Gould <jgo...@verisign.com>, Pat Moroney <pmoro...@name.com> Cc: Andreas Huber <ahu...@united-domains.de>, "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] AW: [regext] REGEXT Fee Document Folks, i really don’t like seeing the Fee Extension getting even more complicated than it currently is. The „class“ of a domain is clearly an attribute of the domain object, not the command. A *domain* is typically classified as a „Premium Name“, not the „renew“. If a domain of that class has a a command with pricing that is identical to the „standard“ pricing, then this is simply a choice of the registry, but the name itself is still a „Premium Name“. On a practical perspective (and to make life as easy as possible for registrars as well as ourselves), i find it highly practical to not require a premium extension on transactions where the price for a command is identical tot he standard pricing. A very practical example (and common case) of that is: - Domain has non-standard „create“ pciring, but standard „renew“ pricing. - „create domain“ requires obviously the fee extension, so that the registrar (and in turn the registrant) acknowledge the higher create price - However, a subsequent transfer would incur standard costs – therefore no acknowledgement of the registrar is needed – fee extension is optional That is implemented in our system, and essentially allows registrars without an implementation of the Fee Extension to perform transfers of „premium names“, as long as the name did incur just a higher create fee. But, coming back to the „object vs. Command level“ discussion – again, let’s not add yet another dimension of complexity. The launch phases will add enough complexity already. Otherwise we’ll end up with no implementation on either side (since registrars as well as registries seem tob e fairly happy with draft version -06 or -07 anyways). Best, Alex Von: regext [mailto:regext-boun...@ietf.org] Im Auftrag von Gould, James Gesendet: Montag, 20. November 2017 22:21 An: Pat Moroney <pmoro...@name.com> Cc: Andreas Huber <ahu...@united-domains.de>; regext@ietf.org Betreff: Re: [regext] REGEXT Fee Document Pat, I agree that 2.d is highly unlikely, but the protocol needs to support the broadest set of possible practices. Roger, do you see an issue in adding the definition of the OPTIONAL “standard” attribute on the <fee:command> element with a default value of “0” (or “false”), that indicates whether the command fees match the “standard” classification command fees? I’ve attached a sample XSD (fee-0.25.xsd) that incorporates this as well as sample XML for a valid check response (good-check-response.xml), a valid check response using partial failure (good-check-response-partial-fail.xml), and a valid check response (good-check-response-fast-fail.xml) using fast fail. — JG [cid:image002.png@01D363A0.E9112B10] 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<mailto:pmoro...@name.com>> Date: Saturday, November 18, 2017 at 12:53 AM To: James Gould <jgo...@verisign.com<mailto:jgo...@verisign.com>> Cc: Andreas Huber <ahu...@united-domains.de<mailto:ahu...@united-domains.de>>, "regext@ietf.org<mailto:regext@ietf.org>" <regext@ietf.org<mailto:regext@ietf.org>> Subject: [EXTERNAL] Re: [regext] REGEXT Fee Document 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<mailto: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 [age001.png] James Gould Distinguished Engineer jgo...@verisign.com<http://jgo...@verisign.com> 703-948-3271<tel:(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<mailto:pmoro...@name.com>> Date: Friday, November 17, 2017 at 1:36 AM To: James Gould <jgo...@verisign.com<mailto:jgo...@verisign.com>> Cc: Andreas Huber <ahu...@united-domains.de<mailto:ahu...@united-domains.de>>, "regext@ietf.org<mailto:regext@ietf.org>" <regext@ietf.org<mailto: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<mailto:jgo...@verisign.com> 703-948-3271<tel:(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<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<tel:(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
