Re: [regext] draft-ietf-regext-epp-fees
ept fees >> which are higher than the actually assessed fees. > >I do suggest that the text says something like the following only (only >make clear that fees must be sufficient, but don't specify what happens >if they are above the required value): > >"A server MUST reject a transform command if client supplied fee values >for the fees involved in the transaction are lower than the server >requires" > >(in better english ;) > >Alex > > >___ >regext mailing list >regext@ietf.org >https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_ >listinfo_regext&d=DwIFAw&c=MOptNlVtIETeDALC_lULrw&r=XJpLGAYHqo0Qxw2Kvg7mfn >ZOGGHKaGjevV2N8lDb4mU&m=6ZnnmrNdgvd01-Bs3v8GcJ_rWCJqhjTwRL2it_VMQCU&s=jGL9 >-go8JMg-qLtcWgfWYImA0Gqy2N10SGPy8eZiRyo&e= > >___ >regext mailing list >regext@ietf.org >https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_ >listinfo_regext&d=DwIFAw&c=MOptNlVtIETeDALC_lULrw&r=XJpLGAYHqo0Qxw2Kvg7mfn >ZOGGHKaGjevV2N8lDb4mU&m=6ZnnmrNdgvd01-Bs3v8GcJ_rWCJqhjTwRL2it_VMQCU&s=jGL9 >-go8JMg-qLtcWgfWYImA0Gqy2N10SGPy8eZiRyo&e= ___ 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
Re: [regext] REGEXT Interim Meeting
We actually request fees for future phases so we can sell pre-registrations
and the like. Removing all references to launch phases would prevent that
ability and make things much more complex and prone to errors.
Thanks,
-Pat
On Wed, Jul 12, 2017 at 6:41 AM Thomas Corte wrote:
> Alexander,
>
> On 12/07/2017 09:26, Alexander Mayrhofer wrote:
>
> > Later during the day yesterday, i
> > came up with a very simple requirement that i think would cover my
> > concerns regarding mixing in launch phases in the fee document:
> >
> > - The Fee Extension MUST provide full functionality with
> > registries implementations which are unaware of the Launch Phase
> extension.
>
> Hmm, but how exactly would you define "full functionality" in this
> context? Requiring to read each "MAY"/"SHOULD" as a "MUST"?
>
> > I think that pretty much covers it. Everything else would be dangerous
> > mixup. My personal preference is still to investigate why exactly the
> > „class“ functionality does not cover Thomas‘ use cases anymore, because
> > i’d like to see the launch phases be completely disconnected from the
> > Fees document.
>
> Old versions of the draft treated the "class" attribute as a pure
> *return* value, i.e. it never appeared in any command, just in responses.
> Hence we saw it as an option (which we also discussed with Gavin Brown
> back then) to return the correct launch phase as a class.
>
> Later versions of the document added the class to the commands, and also
> required to use specific class names ("standard") in certain situations.
> This would have required an awkward mapping from e.g. the launch phase
> name "open" to "standard". At the same time, the draft added dedicated
> launch phase support, which gave us a more elegant way to solve our issues.
>
> The more I think about it, the more I agree that launch phases have
> indeed no place in the fee extension *at all*. With the changes
> introduced yesterday, the fee extension does not provide any
> helpful information with regard to launch phases; actually it now even
> requires the registrar to have a hunch about which of multiple active
> launch phase may be suitable for a name in order to obtain fee information.
> My preference would therefore be to either leave the draft as it is, or
> the remove all references to launch phases completely.
>
> Best regards,
>
> Thomas
>
> --
> TANGO REGISTRY SERVICES® is a product of:
> Knipp Medien und Kommunikation GmbH
> Technologiepark Phone: +49 231 9703-222
> <+49%20231%209703222>
> Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200
> <+49%20231%209703200>
> D-44227 Dortmund E-Mail: supp...@tango-rs.com
> Germany
>
> ___
> 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
Re: [regext] REGEXT Fee Document
To address "2: Appropriate level of ": 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 wrote: > > > 1. "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 s. The > > question raised specifically was "Should a partial result set the > > "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 element is true and if no > elements are present in a 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 , see section 3.7 for more details. > > There has been an ongoing discussion on moving the element to > > the object level (i.e. at the level versus the level). > > Currently the draft has this at the level but I do believe in > > the merits of the argument that in reality/practice 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, , 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
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 wrote: > Pat, > > > > The classification () is an object-level attribute as defined > in section 3.7 (Classification of Objects), so the should be > placed under the instead of the element. Placing it > under the 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 on behalf of Pat Moroney < > pmoro...@name.com> > *Date: *Thursday, November 16, 2017 at 3:08 AM > *To: *Patrick Mevzek > *Cc: *"regext@ietf.org" > *Subject: *[EXTERNAL] Re: [regext] REGEXT Fee Document > > > > To address "2: Appropriate level of ": > > 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 wrote: > > > > 1. "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 s. The > > question raised specifically was "Should a partial result set the > > "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 element is true and if no > elements are present in a 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 , see section 3.7 for more details. > > There has been an ongoing discussion on moving the element to > > the object level (i.e. at the level versus the level). > > Currently the draft has this at the level but I do believe in > > the merits of the argument that in reality/practice 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, , 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
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 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 > Reston, VA 20190 > > 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, > > should be under . 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 . 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, 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 () > should be placed in the location that reflects the definition to remove any > confusion, which is under the 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 ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
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 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 > element up from the element to the > 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 > 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 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 > () 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 > *Date: *Friday, November 17, 2017 at 1:36 AM > *To: *James Gould > *Cc: *Andreas Huber , "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
