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