Subject: [regext] draft-ietf-regext-epp-fees

From: Roger D Carney <[email-masked]>
Date: Wed, 29 Mar 2017 14:05:05 +0000

Good Morning,

We had a very productive meeting at our IETF-98 Monday session.

A few of the items that we resolved Monday include:

*         Simplifying the <check> request by removing the <fee:object> from the extension. This is more in line with Option C from last year's discussions. It does eliminate some flexibility that v0.15 provided. But generally everyone agreed that the flexibility was not worth the expense and that it in practice many preferred the simple approach.

*         Agreement on failing a create when the passed in fee is not equal to or greater than what the server expects. Language will be added.

*         Agreement that balance information in the <check> response is not desirable.

One topic that was not resolved was around the <check> response when the domain(s) are premium (a label that will require fee data on the <create> command to succeed) and no fee extension data is passed by the client. There were two main thoughts on this:

*         If a premium domain is available then it should return available if no fee extension data is provided in the request.

*         Returning unavailable was discussed for a couple reasons. First if no fee data is passed in the <check> and you return available and then the client tries to do the <create> with no fee data (assuming since they did not provide in the <check> they will likely not provide in the <create>), the <create> would fail. Along with this it was discussed that there are and will be many registrars that do/will not participate in premium sales (not using the fee extension). The thought is that returning unavailable will provided a much better backwards compatibility experience.

Please share your thoughts on the premium <check> response when no fee extension data is provided by the client.

Another topic discussed at Monday's session and being discussed on list revolves around the optional fee avail flag and its scope within the <check> response. Currently (v0.15) the optional fee avail flag is at the <fee:command> level. Several have suggested moving this up one level to the <fee:objId> level mostly in order to provide a more efficient way to fail fast. Others like the current (v0.15) solution as it provides more details around the issues causing the false response. I wonder if we provide this optional flag at both levels?

I have started work on v3 (0.17) of the draft with these changes in mind.

Also, please let me know if I missed anything from Monday's discussions.

Thanks
Roger

---

From: Thomas Corte <[email-masked]>
Date: Wed, 29 Mar 2017 16:36:47 +0200

Hello Roger,

On 29/03/2017 16:05, Roger D Carney wrote:

> ·         Simplifying the <check> request by removing the <fee:object>
> from the extension. This is more in line with Option C from last year’s
> discussions. It does eliminate some flexibility that v0.15 provided. But
> generally everyone agreed that the flexibility was not worth the expense
> and that it in practice many preferred the simple approach.

Sounds good.

> ·         Agreement on failing a create when the passed in fee is not
> equal to or greater than what the server expects. Language will be added.

Indeed, the fees themselves should be a perfect match.
Our current implementation uses a somewhat fuzzy comparison regarding
application time, refundability and grace period though; if the registrar
specifies them, any mismatch causes a fail response, otherwise the server
assumes that the registrar "doesn't care" and lets the command succeed.

> One topic that was not resolved was around the <check> response when the
> domain(s) are premium (a label that will require fee data on the <create>
> command to succeed) and no fee extension data is passed by the client.
> There were two main thoughts on this:
> 
> ·         If a premium domain is available then it should return
> _available_ if no fee extension data is provided in the request.
> 
> ·         Returning _unavailable_ was discussed for a couple reasons.
> First if no fee data is passed in the <check> and you return available
> and then the client tries to do the <create> with no fee data (assuming
> since they did not provide in the <check> they will likely not provide in
> the <create>), the <create> would fail. Along with this it was discussed
> that there are and will be many registrars that do/will not participate
> in premium sales (not using the fee extension). The thought is that
> returning unavailable will provided a much better backwards compatibility
> experience.
> 
> Please share your thoughts on the premium <check> response when no fee
> extension data is provided by the client.

I'd strongly prefer the second option, i.e. returning unavailable if a
premium domain is checked without specifying further data. The general
rationale here is that a "plain" <domain:check>'s availability result
should always match the corresponding "plain" <domain:create>'s result.
If a <domain:create> requires special fee-related measures to succeed,
then the <domain:check> should require similar measures to return "domain
available".

> Another topic discussed at Monday’s session and being discussed on list
> revolves around the optional fee avail flag and its scope within the
> <check> response. Currently (v0.15) the optional fee avail flag is at the
> <fee:command> level. Several have suggested moving this up one level to
> the <fee:objId> level mostly in order to provide a more efficient way to
> fail fast. Others like the current (v0.15) solution as it provides more
> details around the issues causing the false response. I wonder if we
> provide this optional flag at both levels?

As I wrote in an earlier mail, I don't believe having the avail attribute
on both levels is needed. It could be moved to the framing element for
each domain; if false, the element would not contain any <command>
elements with pricing information, and if true, the element would only
contain <command> elements that would have had avail=true in the fee-0.15
version. For example, this fee-0.15 response:

S:       <chkData xmlns="urn:ietf:params:xml:ns:fee-0.15">
S:         <cd>
S:           <objID>premium-500.example</objID>
S:           <currency>EUR</currency>
S:           <command avail="false" name="create" phase="open">
S: 	       <reason>the requested launch phase is not suitable for the
domain</reason>
S: 	     </command>
S:           <command name="create" phase="custom" subphase="open-500">
S:             <period unit="y">1</period>
S:             <fee applied="immediate" description="domain creation in
phase 'open-500'" grace-period="PT1M" refundable="true">500.00</fee>
S:           </command>
S:         </cd>
S:       </chkData>

could look like this instead:

S:       <fee:chkData
S:         xmlns:fee="urn:ietf:params:xml:ns:fee-0.xx">
S:         <fee:currency>EUR</fee:currency>
S:         <fee:cd avail="1">
S:           <fee:objID>premium-500.example</fee:objID>
S:           <fee:command name="create"
S:             phase="custom" subphase="open-500">
S:             <fee:period unit="y">1</fee:period>
S:             <fee:fee applied="immediate"
S:               description="domain creation in phase 'open-500'"
grace-period="PT1M" refundable="true">500.00</fee:fee>
S:           </fee:command>
S:         </fee:cd>
S:       </fee:chkData>

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark                             Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
D-44227 Dortmund                       E-Mail: [email-masked]
Germany

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 29 Mar 2017 16:25:45 +0000

Hello Roger, all,

(sorry for the crappy HTML format, my responses tagged below with "Alex>"

Alex> I agree to this. It seemed wasteful to have the fee:object there, and in my discussions with registrars i found out there are very few corner cases in which you would do a fees check for just a selected subset of the domains "checked" in the "regular" check section.

Alex> Yes, please. Allowing a transaction through when the "bid" is not sufficient is plain dangerous.

Alex> Fine with me - i understand it can have serious performance impacts in some installations, and i also understand that the balance check and the object check might not be relevant to the same "departments" of a registrar.

Alex> I'm still for returning "unavailable", because from what i've heard registrars who support the fee extension are typically adding it to each check they do anyways. Which means that only those registrars do *not* add the extension who wouldn't be able to supply the required extension in the subsequent "create" command anyways.  Since "available under certain conditions" is not an option, i'd rather tend to "unavailable", with a reason of "fee extension required".

Alex> I think we need to be very very clear what the "avail" attribute on either of the levels imply. We should *really* try to stick to the purpose of this extension, which is about *fees*. In detail:

-          I think it would be highly confusing and redundant to have it at both levels. This would mean we have three instances of "avail" attributes in a check response (including the one from the "regular" check).

-          As i have said before, "avail" on the command level seems overarching to me, if this is supposed to indicate whether a certain command (with a certain period, a certain phase, and a certain currency?) is available at this point in time. That's overlaying too many policy engine decisions, and sounds scary to me (besides that it has nothing to do with fees anymore - it's wrapping in "more stuff")

-          Then again, the "avail" attribute on the fee:objID would essentially be a 1:1 copy of the "regular" "avail" attribute - which is redundant too.  Adding data to a machine-to-machine protocol just for the purpose of comfort seems weird to me.

Therefore, thinking about all that, i suggest that we simply remove the "avail" attribute from the extension *unless* we find a really precise semantic definition of its meaning.

We should keep the purpose of this check to *fees*, not make it a generic "policy query oracle" which command is available under which conditions.

best,
Alex

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 29 Mar 2017 16:37:08 +0000

[ i hate responding to my own message, but i think i need to add something ]

I wrote my message under the impression that it was suggested to change the semantics of the "avail" flag, which is currently defined as:

   The <fee:command> element also has an OPTIONAL "avail" attribute
   which is a boolean.  If the value of this attribute evaluates to
   false, this indicates that the server cannot calculate the relevant
   fees, because the object, command, currency, period or class is
   invalid according to server policy.

The key part here is "indicates that the server cannot calculate the relevant fees". It should *not* imply that the command in question would be available for the given combination. I suggest that we simply truncate that paragraph to

   The <fee:command> element also has an OPTIONAL "avail" attribute
   which is a boolean.  If the value of this attribute evaluates to
   false, this indicates that the server cannot calculate the relevant
   fees.

It still has the potential for confusion with the semantics of "this command is available" rather than "we could calculate fees". We could clear this up by renaming the attribute to "feeavail" (or anything less awkward than that, just something that does not collide with the "regular" avail attribute) ?

If we keep it, my preference would be to keep it on the command level, because a registry might be able to calculate fees for one command in the set, but not for another, so it should be specific to a certain combination.

Alex

best,
Ale

---

From: Thomas Corte <[email-masked]>
Date: Wed, 29 Mar 2017 18:50:57 +0200

Hello,

On 29/03/2017 18:25, Alexander Mayrhofer wrote:

> Alex> Yes, please. Allowing a transaction through when the “bid” is not
> sufficient is plain dangerous.

I just realized that the agreement seems to be that it is OK to specify a
larger fee than actually charged by the server.

I don't think this is a good idea, I'd prefer requiring a perfect match
of all fees. Sure, allowing the specification of larger fees still guards
the registrar from losing money, but it will also potentially lead to the
registrar unintendedly overcharging a customer if e.g. fees are
statically configured in a registrar's system, and a price change
notification is missed.

It also raises the question what to do when multiple fees are involved.
If the server e.g. charges 50 for creating an initial application
(immediate) and 50 later upon a domain's allocation (delayed), should the
server accept it if the registrar specifies 60 (immediate) and 40
(delayed), i.e. if the total sum of the fees in the create request is
sufficient, but the individual amounts don't match?

At the very least, I'd leave it up to a server's policy to accept fees
which are higher than the actually assessed fees.

Best regards,

Thomas

---

From: "Gould, James" <[email-masked]>
Date: Wed, 29 Mar 2017 17:04:23 +0000

Alex,

The availability of the domain name and the availability of the fee information can be separate.  Consider the use case where a client does a check for an existing domain name (e.g., “existing-domain.example”), where the availability check returns “false” but the fee extension could return the fee information, which may be useful if the existing domain name is in pendingDelete.  Let me be clear that the fee information for an existing domain name is based strictly off the fee tables and not looking at the fee and credit information of the existing domain itself.  The opposite case is sending a check for an available domain name (e.g., “invalid-currency.example”) with an invalid currency.  In this case, the availability check would return “true” but the fee extension would return “false” at the object level.  It’s best to separate the availability values, where the availability of the object is based on the availability for registration and the availability of the fee is based on the availability of the fee information.  I believe it’s best to support a fast-fail at the object level by including the avail attribute at the <fee:objID> level and leave the avail attribute out of the <fee:command> level.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

From: regext <[email-masked]> on behalf of Alexander Mayrhofer <[email-masked]>
Date: Wednesday, March 29, 2017 at 11:37 AM
To: Alexander Mayrhofer <[email-masked]>, Roger Carney <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [regext] draft-ietf-regext-epp-fees

I wrote my message under the impression that it was suggested to change the semantics of the “avail” flag, which is currently defined as:

The key part here is “indicates that the server cannot calculate the relevant fees”. It should *not* imply that the command in question would be available for the given combination. I suggest that we simply truncate that paragraph to

It still has the potential for confusion with the semantics of “this command is available” rather than “we could calculate fees”. We could clear this up by renaming the attribute to “feeavail” (or anything less awkward than that, just something that does not collide with the “regular” avail attribute) ?

Alex

Alex> I think we need to be very very clear what the “avail” attribute on either of the levels imply. We should *really* try to stick to the purpose of this extension, which is about *fees*. In detail:

-          I think it would be highly confusing and redundant to have it at both levels. This would mean we have three instances of “avail” attributes in a check response (including the one from the “regular” check).

-          As i have said before, “avail” on the command level seems overarching to me, if this is supposed to indicate whether a certain command (with a certain period, a certain phase, and a certain currency?) is available at this point in time. That’s overlaying too many policy engine decisions, and sounds scary to me (besides that it has nothing to do with fees anymore – it’s wrapping in “more stuff”)

-          Then again, the “avail” attribute on the fee:objID would essentially be a 1:1 copy of the “regular” “avail” attribute – which is redundant too.  Adding data to a machine-to-machine protocol just for the purpose of comfort seems weird to me.

Therefore, thinking about all that, i suggest that we simply remove the “avail” attribute from the extension *unless* we find a really precise semantic definition of its meaning.

We should keep the purpose of this check to *fees*, not make it a generic “policy query oracle” which command is available under which conditions.

best,
Ale

---

From: Thomas Corte <[email-masked]>
Date: Wed, 29 Mar 2017 19:25:51 +0200

Hello James,

On 29/03/2017 19:04, Gould, James wrote:

> The availability of the domain name and the availability of the fee
> information can be separate.  Consider the use case where a client does a
> check for an existing domain name (e.g., “existing-domain.example”),
> where the availability check returns “false” but the fee extension could
> return the fee information, which may be useful if the existing domain
> name is in pendingDelete.  Let me be clear that the fee information for
> an existing domain name is based strictly off the fee tables and not
> looking at the fee and credit information of the existing domain itself. 

I think it may in some cases be necessary to actually look at the domain
instead of some static "fee table". E.g. it's possible that the domain,
at the time when it was created, was on some "premium" list that caused a
certain set of higher tariffs (also for renewals and transfer) to be
permanently attached to it. This would mean that any registrar who
transfers the domain to his account needs to be aware of the higher costs.

That domain name could have been subsequently taken off the "premium"
list, but that doesn't necessarily change the pricing for the existing
domain. In this situation, the "static" pricing looks normal to the
server, while the actual pricing for the existing domain is still higher
than normal. If the <fee:check> command would only look at a static
"premium" name list, it would return a wrong pricing information to e.g.
a registrar that wants to transfer the name, or renew it.

In fact, one of the main reasons why we implemented the fee extension in
our system is to ensure that registrars don't accidentally transfer
domain names into their portfolio that involve higher costs due to the
configuration of the system at the time of their creation.

Best regards,

Thomas

---

From: Jody Kolker <[email-masked]>
Date: Wed, 29 Mar 2017 17:35:47 +0000

Just to be clear, as a registrar performs a fee check, we expect to receive the command cost for the domain at the time the check is performed, not what it was at the time of creation.  We also expect that fees for domains are not changed without registrars being notified well in advance.

Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall ([email-masked]) with any feedback.

This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments.

-----Original Message-----
From: regext [mailto:[email-masked]] On Behalf Of Thomas Corte
Sent: Wednesday, March 29, 2017 12:26 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [regext] draft-ietf-regext-epp-fees

Hello James,

On 29/03/2017 19:04, Gould, James wrote:

> information can be separate.  Consider the use case where a client 
> does a check for an existing domain name (e.g., 
> "existing-domain.example"), where the availability check returns 
> "false" but the fee extension could return the fee information, which 
> may be useful if the existing domain name is in pendingDelete.  Let me 
> be clear that the fee information for an existing domain name is based 
> strictly off the fee tables and not looking at the fee and credit information of the existing domain itself.

I think it may in some cases be necessary to actually look at the domain instead of some static "fee table". E.g. it's possible that the domain, at the time when it was created, was on some "premium" list that caused a certain set of higher tariffs (also for renewals and transfer) to be permanently attached to it. This would mean that any registrar who transfers the domain to his account needs to be aware of the higher costs.

That domain name could have been subsequently taken off the "premium"
list, but that doesn't necessarily change the pricing for the existing domain. In this situation, the "static" pricing looks normal to the server, while the actual pricing for the existing domain is still higher than normal. If the <fee:check> command would only look at a static "premium" name list, it would return a wrong pricing information to e.g.
a registrar that wants to transfer the name, or renew it.

In fact, one of the main reasons why we implemented the fee extension in our system is to ensure that registrars don't accidentally transfer domain names into their portfolio that involve higher costs due to the configuration of the system at the time of their creation.

Best regards,

Thomas

_______________________________________________
regext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/regext

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 29 Mar 2017 21:35:30 +0000

> larger fee than actually charged by the server.

Yes. And i think it's good.

> statically configured in a registrar's system, and a price change

We can never prevent registrars from "overcharging" a customer, and i do consider it out of scope for the IETF. What i don't consider out of scope of the IETF, however, is the robustness principle of "be conservative what you send, be liberal in what you accept". Especially in situations where there's a rush for names, a failed transaction just because someone "overbid" the registry could create problems.

Further, requiring a "perfect match" would prevent models like dutch auctions, where prices slowly decrease over time. A check could never reflect the actual, current price, so "overbidding" is required in such situations. More hypothetically, but, possible. 

> sufficient, but the individual amounts don't match?

No. Each fee involved would need to be equal or over the fee required by the server.

> 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

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 29 Mar 2017 21:48:29 +0000

James Gould wrote:
> The availability of the domain name and the availability of the fee information 
> can be separate. 

I understand that. If the *only* semantics of the "avail" attribute is to provide the (redundant) 
information that "fee" elements are contained in the "command" element, then fair enough - it's still a redundant element, because it's sole purpose is then to indicate whether the "command" element contains "fee" elements (or not). 

I just don't want situations in which clients would interpret the "avail" flag as an indication that the
respective command *will go through* (similar to what the "avail" attribute on the regular section of 
the check command implies  for the "create" command).

That's why i suggested truncating the respective definition to its core meaning.

> Consider the use case where a client does a check for
> an existing domain name (e.g., “existing-domain.example”), where the availability 
> check returns “false” but the fee extension could return the fee information, which 
> may be useful if the existing domain name is in pendingDelete.

That's fine, of course. But whether or not fees are available could also be deducted from the 
fact that they are actually included in the response?

>  Let me be clear
> that the fee information for an existing domain name is based strictly off the fee 
> tables and not looking at the fee and credit information of the existing domain itself.  

Interesting point. Of course, for the sake of simplicity, i'm with you. However, I *could* think of situations where renewal of an *existing* domain name has a different price compared to the renewal price if said domain was deleted and picked up on a (now different, lower) price class.

But i don't want to go there.

> The opposite case is sending a check for an available domain name (e.g., “invalid-currency.example”)
>  with an invalid currency.  In this case, the availability check would return
> “true” but the fee extension would return “false” at the object level. 

Understood, and agreed.

>  It’s best to separate the availability values, where the availability of the object is based 
> on the availability for registration and the availability of the fee is based on the availability 
> of the fee information.  I believe it’s best to support a fast-fail at the object level
> by including the avail attribute at the <fee:objID> level and leave the avail 
> attribute out of the <fee:command> level.    

Again, i do understand the difference between domain availability and fee information availability - but, again, the information whether or not fee information is available can be deducted from the presence of the *actual* fee elements, hence that element is syntactic "fluff", isn't it?

best,
Alex

---

From: Thomas Corte <[email-masked]>
Date: Thu, 30 Mar 2017 10:31:50 +0200

Hello,

On 2017-03-29 23:48, Alexander Mayrhofer wrote:

>> Let me be clear that the fee information for an existing domain
>> name is based strictly off the fee tables and not looking at the
>> fee and credit information of the existing domain itself.
> 
> Interesting point. Of course, for the sake of simplicity, i'm with
> you. However, I *could* think of situations where renewal of an
> *existing* domain name has a different price compared to the renewal
> price if said domain was deleted and picked up on a (now different,
> lower) price class.
> 

Unfortunately, sometimes real life goes where engineers would rather not
go. In one of our TLDs, we'll soon face a situation where exactly this
happens - some "legacy" premium domain names will retain a higher price
- also for future (auto-)renewals and transfers - compared to newly
created premium names (this approach was not my choice, but couldn't be
helped). Deleting and recreating such a domain would save the registrar
money, however this would cause the name to go on hold for at least 30
days during the RGP.

I hope we can agree that in such a situation, the *only* useful fee
information (e.g. about the cost for a transfer of an affected domain)
is the *actual* fee attached to the existing domain object, and not the
*theoretical* (lower) fee that would be charged if the same name was
recreated in the system that was reconfigured since the domain was
created, no?

Best regards,

Thomas

---

From: Jody Kolker <[email-masked]>
Date: Thu, 30 Mar 2017 12:49:05 +0000

Hi,

Thomas wrote:

<<

I hope we can agree that in such a situation, the *only* useful fee information (e.g. about the cost for a transfer of an affected domain) is the *actual* fee attached to the existing domain object, and not the
*theoretical* (lower) fee that would be charged if the same name was recreated in the system that was reconfigured since the domain was created, no?

Thomas - as a registrar that might be able to register/renew/transfer the domain, I only care what the domain would cost for be to perform those actions at the current time or a phase in the future.  I'm not concerned with the cost in the past as I have already been charged for that cost and I should have logging or other form of documentation to prove it.  

Thanks,
Jody Kolker
319-294-3933 (office)

-----Original Message-----
From: regext [mailto:[email-masked]] On Behalf Of Thomas Corte
Sent: Thursday, March 30, 2017 3:32 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [regext] draft-ietf-regext-epp-fees

Hello,

On 2017-03-29 23:48, Alexander Mayrhofer wrote:

>> Let me be clear that the fee information for an existing domain name 
>> is based strictly off the fee tables and not looking at the fee and 
>> credit information of the existing domain itself.
> 

Unfortunately, sometimes real life goes where engineers would rather not go. In one of our TLDs, we'll soon face a situation where exactly this happens - some "legacy" premium domain names will retain a higher price
- also for future (auto-)renewals and transfers - compared to newly created premium names (this approach was not my choice, but couldn't be helped). Deleting and recreating such a domain would save the registrar money, however this would cause the name to go on hold for at least 30 days during the RGP.

I hope we can agree that in such a situation, the *only* useful fee information (e.g. about the cost for a transfer of an affected domain) is the *actual* fee attached to the existing domain object, and not the
*theoretical* (lower) fee that would be charged if the same name was recreated in the system that was reconfigured since the domain was created, no?

Best regards,

Thomas

---

From: Jody Kolker <[email-masked]>
Date: Thu, 30 Mar 2017 12:50:17 +0000

Alex wrote:

Agreed.

Thanks,
Jody Kolker
319-294-3933 (office)

-----Original Message-----
From: regext [mailto:[email-masked]] On Behalf Of Alexander Mayrhofer
Sent: Wednesday, March 29, 2017 4:36 PM
To: Thomas Corte <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [regext] draft-ietf-regext-epp-fees

Thomas Corte wrote:
> I just realized that the agreement seems to be that it is OK to 
> specify a larger fee than actually charged by the server.

> I don't think this is a good idea, I'd prefer requiring a perfect 
> match of all fees. Sure, allowing the specification of larger fees 
> still guards the registrar from losing money, but it will also 
> potentially lead to the registrar unintendedly overcharging a customer 
> if e.g. fees are statically configured in a registrar's system, and a 
> price change notification is missed.

> (immediate) and 50 later upon a domain's allocation (delayed), should 
> the server accept it if the registrar specifies 60 (immediate) and 40 

(in better english ;)

Alex

---

From: Thomas Corte <[email-masked]>
Date: Thu, 30 Mar 2017 15:09:38 +0200

Hello Jody,

On 2017-03-30 14:49, Jody Kolker wrote:

>> information (e.g. about the cost for a transfer of an affected
>> domain) is the *actual* fee attached to the existing domain object,
>> and not the *theoretical* (lower) fee that would be charged if the
>> same name was recreated in the system that was reconfigured since
>> the domain was created, no?
> 
> Thomas - as a registrar that might be able to register/renew/transfer
> the domain, I only care what the domain would cost for be to perform
> those actions at the current time or a phase in the future.  I'm not
> concerned with the cost in the past as I have already been charged
> for that cost and I should have logging or other form of
> documentation to prove it.

Sure, that's reasonable (and trust me, I'm wearing my registrar hat
often enough to be very aware of a registrar's needs when it comes to EPP).
But I'm not talking about returning fees from the past, I'm talking
about returning future fees that are determined by a specific domain's
past, such as the point in time when it was created.

In the real-world scenario I described, it is possible that the monthly
transfer/renewal fee for a domain is f1, and to find f1 the server has
to actually look at the domain in the database to retrieve the launch
phase lp1 in which the domain was originally created. Note that lp1 may
already be over, but still determines the fee f1 charged for domains
created in it. If the same domain was deleted and recreated after the
RGP (then in a different launch phase lp2), the monthly transfer/renewal
fee would be f2 instead, with f2 potentially being different from f1.

Now, what I'm saying is that a <fee:check> command asking for the costs
for a transfer/renewal of the domain created in lp1 should return f1
rather than f2, since only f1 represents the actual fee the server will
charge for the domain. This speaks in favor of a "dynamic" fee lookup
potentially involving the actually registered domain, rather than just
looking at the system's current "static" fee configuration.

Best regards,

Thomas

---

From: "Feher, Kal" <[email-masked]>
Date: Thu, 30 Mar 2017 16:40:43 +0000

I personally think an exact match is best. The represented fee is that of
the server, not what the Registrar will charge the registrant (which could
be above or below the registry price).

If we want to ensure that the Registrar correctly understands the price at
the time of transaction, then exact match is the only mechanism to be sure
of this.

With our own extension for premium names we had exactly this discussion
internally and ultimately opted for either an exact match or a simple
'non-standard price' acknowledgement. The reasoning being that if a
Registrar specified a price, they wanted to ensure correctness and if a
Registrar specified an acknowledgment they were satisfied using
offline/out of band sources for price.

Since discounting and mark up pricing are normal practices for Registrars,
we can't presume that an incorrect value in either direction (above or
below) is acceptable.

My 2 cents (in AUD so therefore 1.6 cents)

I originally posted this reply using a non-subscribed address, so
apologies to those who've received it twice.

On 30/3/17, 07:50, "regext on behalf of Jody Kolker"
<[email-masked] on behalf of [email-masked]> wrote:

>319-329-9805 (mobile) Please contact my direct supervisor Charles
>Beadnall ([email-masked]) with any feedback.
>
>This email message and any attachments hereto is intended for use only by
>the addressee(s) named herein and may contain confidential information.
>If you have received this email in error, please immediately notify the
>sender and permanently delete the original and any copy of this message
>and its attachments.
>
>
>
>We can never prevent registrars from "overcharging" a customer, and i do
>consider it out of scope for the IETF. What i don't consider out of scope
>of the IETF, however, is the robustness principle of "be conservative
>what you send, be liberal in what you accept". Especially in situations
>where there's a rush for names, a failed transaction just because someone
>"overbid" the registry could create problems.
>
>Further, requiring a "perfect match" would prevent models like dutch
>auctions, where prices slowly decrease over time. A check could never
>reflect the actual, current price, so "overbidding" is required in such
>situations. More hypothetically, but, possible.
>
>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
>
>
>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=
>
>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=

---

From: Chris Cowherd <[email-masked]>
Date: Thu, 30 Mar 2017 14:36:10 +0000

For Donuts, it would be very important that if the registrar does not pass
in the fee extension on the check, that the domain return unavailable when
premium. The response reason should indicate that it is unavailable because
the name is premium and no fee extension was present in the request.

The check command is a hint that indicates success of a create command. We
don't want to indicate that a create will succeed in the case of a premium
name and no fee extension. I foresee the lack of that breaking many
registrars as we have many that do not participate in selling premium
names.

I apologize that I could not attend to discuss in person.

-- 
Chris Cowherd, CTO Donuts Inc.

---

From: "Feher, Kal" <[email-masked]>
Date: Thu, 30 Mar 2017 16:23:47 +0000

---

From: Pat Moroney <[email-masked]>
Date: Thu, 30 Mar 2017 17:10:33 +0000

I also agree that exact match is best. At the time we issue the create
command, we have already stored what we expect to be charged for that
transaction and used it in other calculations.

Maybe instead of picking one, we can add an attribute to the <fee:fee>
element like <fee:fee match="exact"> where the valid values are "exact", or
"inexact" or better terminology TBD. With exact being the default if it
isn't specified. And of course, we would need a corresponding attribute for
the <fee:credit> element as well.

This allows flexibility and make's the inexact match an explicit choice
made by the registrar.

Thanks,
-Pat

On Thu, Mar 30, 2017 at 10:40 AM Feher, Kal <[email-masked]>
wrote:

On 30/3/17, 07:50, "regext on behalf of Jody Kolker"
<[email-masked] on behalf of [email-masked]> wrote:

>319-294-3933 <(319)%20294-3933> (office)
>319-329-9805 <(319)%20329-9805> (mobile) Please contact my direct
supervisor Charles

-- 
-Pat Moroney
Sr. Software Engineer
Name.com
http://www.youtube.com/watch?v=V1GKGXXF12c
720-663-0025

---

From: "Gould, James" <[email-masked]>
Date: Thu, 30 Mar 2017 17:22:16 +0000

If it were client specified to set the expected behavior, then it may be better to just set a boolean “exact” attribute with a default of “false” to support the language in the draft that the passed in fee can’t be less than the actual fee and when set to “true” the passed in and actual fee must be equal.  This may be a little too flexible, but either we agree to equal, can’t be less than, or we support both with a client specified preference.  I wouldn’t recommend leaving it up to registry policy on this one, since the client would not know what to expect.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

From: regext <[email-masked]> on behalf of Pat Moroney <[email-masked]>
Date: Thursday, March 30, 2017 at 12:10 PM
To: "Feher, Kal" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [regext] draft-ietf-regext-epp-fees

I also agree that exact match is best. At the time we issue the create command, we have already stored what we expect to be charged for that transaction and used it in other calculations.

Maybe instead of picking one, we can add an attribute to the <fee:fee> element like <fee:fee match="exact"> where the valid values are "exact", or "inexact" or better terminology TBD. With exact being the default if it isn't specified. And of course, we would need a corresponding attribute for the <fee:credit> element as well.

This allows flexibility and make's the inexact match an explicit choice made by the registrar.

Thanks,
-Pat

On Thu, Mar 30, 2017 at 10:40 AM Feher, Kal <[email-masked]<mailto:[email-masked]>> wrote:
I personally think an exact match is best. The represented fee is that of
the server, not what the Registrar will charge the registrant (which could
be above or below the registry price).

On 30/3/17, 07:50, "regext on behalf of Jody Kolker"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

>319-294-3933<tel:(319)%20294-3933> (office)
>319-329-9805<tel:(319)%20329-9805> (mobile) Please contact my direct supervisor Charles
>Beadnall ([email-masked]<mailto:[email-masked]>) with any feedback.
>
>From: regext [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alexander
>Mayrhofer
>To: Thomas Corte <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>Cc: [email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>
>[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: Alexander Mayrhofer <[email-masked]>
Date: Thu, 30 Mar 2017 17:25:49 +0000

Hi,

i don’t think we should overengineer here. Before adding yet another attribute which makes things even more complicated, i’m rather with following the majority of opinions that an exact match is required.

My favorite is still reduce the text to keep it intentionally “underspecified”.

best,
Alex

Von: regext [mailto:[email-masked]] Im Auftrag von Gould, James
Gesendet: Donnerstag, 30. März 2017 12:22
An: Pat Moroney; Feher, Kal; [email-masked]
Betreff: Re: [regext] draft-ietf-regext-epp-fees [x_phishing]

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

From: regext <[email-masked]<mailto:[email-masked]>> on behalf of Pat Moroney <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 30, 2017 at 12:10 PM
To: "Feher, Kal" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [regext] draft-ietf-regext-epp-fees

Thanks,
-Pat

---

From: Thomas Corte <[email-masked]>
Date: Fri, 31 Mar 2017 10:43:46 +0200

Hello,

On 30/03/2017 19:22, Gould, James wrote:

> I wouldn’t recommend leaving it up to registry policy on
> this one, since the client would not know what to expect. 

Agreed, it should be left to server policy/configuration whether or not
higher than expected values are accepted. Alexander's point regarding
Dutch auctions is a compelling argument for sometimes accepting higher
fees, even if the server's general policy may be to require an exact match.

Best regards,

Thomas