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.
— 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: Thursday, November 16, 2017 at 9:25 AM To: James Gould <jgo...@verisign.com> Cc: Patrick Mevzek <p...@dotandco.com>, "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] REGEXT Fee Document James, I understand that it is redundant for registries that have the same classes for each type of command. But we use the class information to decide how to price and how to advertise domains. When a class is returned per command, it allows us to know that a domain does have standard renewals, which will allow us to advertise those domains appropriately. So maybe we should change section 3.7. Also, if a domain with standard fees for renewals is given a non-standard class, it requires manual and error-prone work to make sure that they are all priced the same. Which is precisely why I had suggested labeling fees as standard vs non-standard originally. Thanks, -Pat On Wed, Nov 15, 2017 at 5:14 PM Gould, James <jgo...@verisign.com<mailto:jgo...@verisign.com>> wrote: Pat, The classification (<fee:class>) is an object-level attribute as defined in section 3.7 (Classification of Objects), so the <fee:class> should be placed under the <fee:cd> instead of the <fee:command> element. Placing it under the <fee:command> is redundant and can add confusion and complexity if the server does not treat it as an object-level attribute. — JG [cid:image001.png@01D35EB2.F82302B0] 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: regext <regext-boun...@ietf.org<mailto:regext-boun...@ietf.org>> on behalf of Pat Moroney <pmoro...@name.com<mailto:pmoro...@name.com>> Date: Thursday, November 16, 2017 at 3:08 AM To: Patrick Mevzek <p...@dotandco.com<mailto:p...@dotandco.com>> Cc: "regext@ietf.org<mailto:regext@ietf.org>" <regext@ietf.org<mailto:regext@ietf.org>> Subject: [EXTERNAL] Re: [regext] REGEXT Fee Document To address "2: Appropriate level of <fee:class>": There are some TLDs where a domain may have a premium fee for creates, but uses base price for renewals. In those cases it is better to have a class per command, as we want to make different pricing choices based on that class. Thanks, -Pat Moroney On Mon, Nov 13, 2017 at 10:34 PM Patrick Mevzek <p...@dotandco.com<mailto:p...@dotandco.com>> wrote: > 1. <cd> "avail" attribute meaning on partial return of results, see > section 3.9 for some additional context. The extension allows servers > to choose between returning no results or partial results when a server > encounters an issue with one or more of the requested <command>s. The > question raised specifically was "Should a partial result set the <cd> > "avail" attribute to true or false". The intent of the draft was to > return "avail=0" on partial (there was some failure), but some > implementations have interpreted it as "avail=1" (some data returned). > What do people think? Since the client chooses the list of fee:command to include, if some are missing in the reply, I think it means that cd should be zero, because if it is 1, the following sentence, in absence of command elements in reply could lead to wrong conclusions: If the "avail" attribute of the <fee:cd> element is true and if no <fee:fee> elements are present in a <fee:command> element, this indicates that no fee will be assessed by the server for this command. Basically a complete error to set any fee (because of incompatible request parameters from client) may be interpreted as if no fee is needed at all, which is a completely different case. Hence I am in favor of cd=0 as soon as one problem is detected. The client is free to check again with different parameters until it gets cd=1 > 2. Appropriate level of <fee:class>, see section 3.7 for more details. > There has been an ongoing discussion on moving the <class> element to > the object level (i.e. at the <cd> level versus the <command> level). > Currently the draft has this at the <command> level but I do believe in > the merits of the argument that in reality/practice <class> is defined > at the domain object level and not the command level, so unless there > are arguments to keep it at the command level the next version will > move this to the object, <cd>, level. I also believe that we talk about a class for a domain and not a class for a command, so it should be tied at the domain level. This is even what the first sentence of section 3.7 implies. -- Patrick Mevzek p...@dotandco.com<mailto:p...@dotandco.com> _______________________________________________ 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
