Subject: [regext] REGEXT Fee Document

From: Roger D Carney <[email-masked]>
Date: Mon, 13 Nov 2017 08:33:42 +0000

Good Afternoon,

As mentioned today in the REGEXT face to face meeting at IETF-100 in Singapore, we have two remaining questions open on the current draft https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees.

  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?
  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.

After comments have been received and document updated accordingly, we will ask for WGLC.

Thanks
Roger

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 14 Nov 2017 06:34:07 +0100

>   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
  [email-masked]

---

From: Pat Moroney <[email-masked]>
Date: Wed, 15 Nov 2017 19:08:33 +0000

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 <[email-masked]> wrote:

> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext
>
-- 
-Pat Moroney
Sr. Software Engineer
Name.com
http://www.youtube.com/watch?v=V1GKGXXF12c
720-663-0025

---

From: "Gould, James" <[email-masked]>
Date: Thu, 16 Nov 2017 00:14:31 +0000

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

[id:[email-masked]]

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: regext <[email-masked]> on behalf of Pat Moroney <[email-masked]>
Date: Thursday, November 16, 2017 at 3:08 AM
To: Patrick Mevzek <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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

--
  Patrick Mevzek
  [email-masked]<mailto:[email-masked]>

_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext
--
-Pat Moroney
Sr. Software Engineer
Name.com
http://www.youtube.com/watch?v=V1GKGXXF12c
720-663-0025

---

From: Pat Moroney <[email-masked]>
Date: Thu, 16 Nov 2017 01:25:52 +0000

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 <[email-masked]> 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
>
>
>
>
> *James Gould *Distinguished Engineer
> [email-masked]
>
> 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 <[email-masked]> on behalf of Pat Moroney <
> [email-masked]>
> *Date: *Thursday, November 16, 2017 at 3:08 AM
> *To: *Patrick Mevzek <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *[EXTERNAL] Re: [regext] REGEXT Fee Document
>
>
>
> 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
>
>
>
> 720-663-0025 <(720)%20663-0025>
>

---

From: "Gould, James" <[email-masked]>
Date: Thu, 16 Nov 2017 03:44:40 +0000

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

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

From: Pat Moroney <[email-masked]>
Date: Thursday, November 16, 2017 at 9:25 AM
To: James Gould <[email-masked]>
Cc: Patrick Mevzek <[email-masked]>, "[email-masked]" <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Pat,

—

JG

James Gould
Distinguished Engineer
[email-masked]<http://[email-masked]>

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>

From: regext <[email-masked]<mailto:[email-masked]>> on behalf of Pat Moroney <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 16, 2017 at 3:08 AM
To: Patrick Mevzek <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [regext] REGEXT Fee Document

Thanks,
-Pat Moroney

720-663-0025<tel:(720)%20663-0025>

---

From: Andreas Huber <[email-masked]>
Date: Thu, 16 Nov 2017 09:16:59 +0100

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

---

From: "Gould, James" <[email-masked]>
Date: Thu, 16 Nov 2017 09:32:22 +0000

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
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 11/16/17, 4:16 PM, "regext on behalf of Andreas Huber" <[email-masked] on behalf of [email-masked]> wrote:

    Hi all,

    
    
    Thanks,
    Andreas

---

From: Pat Moroney <[email-masked]>
Date: Thu, 16 Nov 2017 17:36:29 +0000

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 <[email-masked]> 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
> [email-masked]
>
> On 11/16/17, 4:16 PM, "regext on behalf of Andreas Huber" <
> [email-masked] on behalf of [email-masked]> 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.).
>
>     > 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.
>     >
>     >
>     >
>     > —
>     >
>     >
>     >
>

---

From: "Gould, James" <[email-masked]>
Date: Thu, 16 Nov 2017 23:39:04 +0000

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

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

From: Pat Moroney <[email-masked]>
Date: Friday, November 17, 2017 at 1:36 AM
To: James Gould <[email-masked]>
Cc: Andreas Huber <[email-masked]>, "[email-masked]" <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Andreas,

—

JG

James Gould
Distinguished Engineer
[email-masked]

On 11/16/17, 4:16 PM, "regext on behalf of Andreas Huber" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    Hi all,

    Thanks,
    Andreas

---

From: Patrick Mevzek <[email-masked]>
Date: Fri, 17 Nov 2017 08:13:22 +0100

> Another solution would be to not transmit standard fees in the fee

I disagree.
Since the "standard" definition is not constant in time nor in space
(amont registries/TLDs),
it is not a good basis to omit fees in any case. The extension is here
to be as specific as possible, this is cleatly not the good spot to try
reducing the bytes count.

-- 
  Patrick Mevzek
  [email-masked]

---

From: Pat Moroney <[email-masked]>
Date: Fri, 17 Nov 2017 16:53:39 +0000

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 <[email-masked]> 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”).
>
> 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
>
>
>
>
>
>
> *From: *Pat Moroney <[email-masked]>
> *Date: *Friday, November 17, 2017 at 1:36 AM
> *To: *James Gould <[email-masked]>
> *Cc: *Andreas Huber <[email-masked]>, "[email-masked]" <
> [email-masked]>
>
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 20 Nov 2017 12:26:12 +0100

On Fri, Nov 17, 2017 at 04:53:39PM +0000,
 Pat Moroney <[email-masked]> wrote 
 a message of 769 lines which said:

> Although I know of no TLD that has a model without a standard fee, I
> can imagine one.

Is it even possible? Since the space of all possible names is
near-infinite, you need a "standard" fee for names that you did not
envision, such as bad06b5cdec0b14542c99c371d757e31.example.

OK, you can have "algorithmic fees" (higher fee if in a dictionary,
lower fees if length > 30 characters...) but it does not cover all
cases.

---

From: "Gould, James" <[email-masked]>
Date: Mon, 20 Nov 2017 14:21:26 +0000

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

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Date: Saturday, November 18, 2017 at 12:53 AM

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 <[email-masked]<mailto:[email-masked]>> wrote:
Pat,

Thoughts?

—

JG

James Gould
Distinguished Engineer

From: Pat Moroney <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 17, 2017 at 1:36 AM
To: James Gould <[email-masked]<mailto:[email-masked]>>
Cc: Andreas Huber <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Thanks,
-Pat Moroney

—

JG

James Gould
Distinguished Engineer
[email-masked]

    Hi all,

    Thanks,
    Andreas

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 21 Nov 2017 04:43:21 +0100

> “standard” classification fees for the command and period.

I am not very happy with the addition of yet another element.
The extension is getting more and more complex.
I believe that such attribute is not completely unrelated to the class
value,
so there is something related to the model that does not feel right to
me.
> domain name, would have standard=”1”.

It shows the two values are not independant, so there is a kind of
duplication
of information.

I think that in that case having the class element per command instead
of per domain would be a better choice than adding an attribute.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Tue, 21 Nov 2017 20:52:09 +0000

Patrick,

The classification is defined at the object level, where in general a domain is either a “standard” domain or a non-“standard” domain (e.g., “premium”, “discount”), but there is an issue with non-“standard” classification objects that is not handled by the <fee:class> element.  Placing the <fee:class> element under the <fee:command> element doesn’t match the definition of the classification as an object-level element, so it is best placed under the <fee:cd> element.  Two registrars (I believe) have expressed the need to know whether a non-“standard” object is using a standard fee for one or more of the commands.  The example given is a “premium” domain that uses a non-standard fee for the create command, but a standard fee for the renew command.  In this case, the <fee:command name=”create”> element would include standard=”0” and the <fee:command name=”renew”> would include standard=”1”.  For a “standard” domain, all of the <fee:command> elements would include standard=”1”, since all of the commands follow the “standard” fee schedule.

Clients can use the <fee:class> as a hint of the fee schedule used for the object and to drive whether the fees are required to be passed with billable commands for non-“standard” objects.  The “standard” fee schedule should be stable and be applicable for a large set of objects.  A non-“standard” classification fee schedule can be variable and be applicable to a smaller set of objects.  The use of the “standard” attribute at the command level provides the client with more information on the drive their decisions.  On the server-side it will require comparing the fee schedule of non-“standard” classifications to the “standard” classification, so there is certainly added complexity.

If you have another proposal to address this use case, please share it.

Thanks, 
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 11/20/17, 10:43 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    

    -- 
      Patrick Mevzek
      [email-masked]

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 22 Nov 2017 07:14:55 +0100

> The classification is defined at the object level, where in general a
> domain is either a “standard” domain or a non-“standard” domain (e.g.,
> “premium”, “discount”),

I agree, this was the opinion I raised at the start of this thread.

> but there is an issue with non-“standard”
> classification objects that is not handled by the <fee:class> element.

I am still not convinced by this issue, nor by your solution to it.
2 registrars voiced their concerns on this case, but I would love to
hear other opinions, including from registries, to make sure that
something new and at the last minute
is not bolted into a standard when it does not have widespread need.

I am even not convinced that what you propose will help the business
case put forward:
since the "standard" attribute which is the core of the solution is
optional per
your suggestion if I read it correctly, registries will be free not to
implement it
in which case the business case being discussed here will remain without
a solution on the field.
So we will a protocol with an optional feature for some use case that
maybe noone will use.
Also, a registry that decides to implement this will have extra work to
do for each command
(like you said: "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.") where maybe no client will be using this attribute
(since it is optional, a registrar dealing with multiple registries will
need to cope with various cases and know how to behave when the
attribute will be absent).    

In short, I do not see a problem of having a reply with
class='notstandard'
for a given domain, and then a set of prices associated.
Some of the prices there may be the same as some of the prices of a
domain with
class='standard' (like the case of a setup where creates are at a
premium price
but not later operations on the domain name).
The registrar can make the difference between the two cases, not by
comparing prices,
but just because the first class will be 'notstandard' meaning that the
domain is
a premium one in some aspect which is what I understood is the need
here.
The name of the class could itself convey enough meaning for that.

I believe that the extension is clear that the class is per-object and
not per-command and hence there is not a standard vs non standard fee,
which is clearly what others are attempting to reach. I do not believe
you can achieve both goals at the same time.
Like you said previously the subject may be too broad and accept
multiple representation: I would prefer that we stick to one, which may
appeal to some and not to others, instead of trying to accomodate too
many disparate or even opposite goals.

> If you have another proposal to address this use case, please share it.

My proposal is to keep things as is, with the class at the object level.

-- 
  Patrick Mevzek
  [email-masked]

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 22 Nov 2017 14:10:49 +0000

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:[email-masked]] Im Auftrag von Gould, James
Gesendet: Montag, 20. November 2017 22:21
An: Pat Moroney <[email-masked]>
Cc: Andreas Huber <[email-masked]>; [email-masked]
Betreff: Re: [regext] REGEXT Fee Document

Pat,

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

James,

Thanks again,
-Pat

Thoughts?

—

JG

James Gould
Distinguished Engineer

Thanks,
-Pat Moroney

—

JG

James Gould
Distinguished Engineer
[email-masked]<mailto:[email-masked]>

    Hi all,

    Thanks,
    Andreas