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> 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 > > > [image: id:image001.png@01D255E2.EB933A30] > > > *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: *regext <regext-boun...@ietf.org> on behalf of Pat Moroney < > pmoro...@name.com> > *Date: *Thursday, November 16, 2017 at 3:08 AM > *To: *Patrick Mevzek <p...@dotandco.com> > *Cc: *"regext@ietf.org" <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> 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 > > _______________________________________________ > 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
