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

2017-03-30 Thread Thomas Corte
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.
> 
> But i don't want to go there.

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

-- 
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: supp...@tango-rs.com
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


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

2017-03-30 Thread Jody Kolker
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)
319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall 
(cbeadn...@godaddy.com) 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:regext-boun...@ietf.org] On Behalf Of Thomas Corte
Sent: Thursday, March 30, 2017 3:32 AM
To: regext@ietf.org
Cc: supp...@tango-rs.com
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.
> 
> 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.

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

--
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: supp...@tango-rs.com
Germany

___
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


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

2017-03-30 Thread Jody Kolker
Alex wrote:

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

Agreed.

Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall 
(cbeadn...@godaddy.com) 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:regext-boun...@ietf.org] On Behalf Of Alexander Mayrhofer
Sent: Wednesday, March 29, 2017 4:36 PM
To: Thomas Corte ; regext@ietf.org
Cc: supp...@tango-rs.com
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.

Yes. And i think it's good.

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

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. 

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

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

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

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://www.ietf.org/mailman/listinfo/regext

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


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

2017-03-30 Thread Thomas Corte
Hello Jody,

On 2017-03-30 14:49, Jody Kolker 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.

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

-- 
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: supp...@tango-rs.com
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


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

2017-03-30 Thread Feher, Kal
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"
 wrote:

>Alex wrote:
>
>>>
>No. Each fee involved would need to be equal or over the fee required by
>the server.
>>>
>
>Agreed.
>
>Thanks,
>Jody Kolker
>319-294-3933 (office)
>319-329-9805 (mobile) Please contact my direct supervisor Charles
>Beadnall (cbeadn...@godaddy.com) 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:regext-boun...@ietf.org] On Behalf Of Alexander
>Mayrhofer
>Sent: Wednesday, March 29, 2017 4:36 PM
>To: Thomas Corte ; regext@ietf.org
>Cc: supp...@tango-rs.com
>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.
>
>Yes. And i think it's good.
>
>> 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.
>
>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.
>
>> 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?
>
>No. Each fee involved would need to be equal or over the fee required by
>the server.
>
>> 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.
>
>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=

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

2017-03-30 Thread Feher, Kal

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)





On 30/3/17, 07:50, "regext on behalf of Jody Kolker"
 wrote:

>Alex wrote:
>
>>>
>No. Each fee involved would need to be equal or over the fee required by
>the server.
>>>
>
>Agreed.
>
>Thanks,
>Jody Kolker
>319-294-3933 (office)
>319-329-9805 (mobile) Please contact my direct supervisor Charles
>Beadnall (cbeadn...@godaddy.com) 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:regext-boun...@ietf.org] On Behalf Of Alexander
>Mayrhofer
>Sent: Wednesday, March 29, 2017 4:36 PM
>To: Thomas Corte ; regext@ietf.org
>Cc: supp...@tango-rs.com
>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.
>
>Yes. And i think it's good.
>
>> 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.
>
>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.
>
>> 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?
>
>No. Each fee involved would need to be equal or over the fee required by
>the server.
>
>> 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.
>
>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/ma

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

2017-03-30 Thread Chris Cowherd
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.
On Thu, Mar 30, 2017 at 6:09 AM Thomas Corte  wrote:

> Hello Jody,
>
> On 2017-03-30 14:49, Jody Kolker 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.
>
> 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  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
>
> --
> 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: supp...@tango-rs.com
> Germany
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>
-- 
Chris Cowherd, CTO Donuts Inc.
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


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

2017-03-30 Thread Pat Moroney
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 
element like  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  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 
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).

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"
 wrote:

>Alex wrote:
>
>>>
>No. Each fee involved would need to be equal or over the fee required by
>the server.
>>>
>
>Agreed.
>
>Thanks,
>Jody Kolker
>319-294-3933 <(319)%20294-3933> (office)
>319-329-9805 <(319)%20329-9805> (mobile) Please contact my direct
supervisor Charles
>Beadnall (cbeadn...@godaddy.com) 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:regext-boun...@ietf.org] On Behalf Of Alexander
>Mayrhofer
>Sent: Wednesday, March 29, 2017 4:36 PM
>To: Thomas Corte ; regext@ietf.org
>Cc: supp...@tango-rs.com
>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.
>
>Yes. And i think it's good.
>
>> 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.
>
>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.
>
>> 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?
>
>No. Each fee involved would need to be equal or over the fee required by
>the server.
>
>> 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.
>
>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
>
>
>__

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

2017-03-30 Thread Gould, James
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

[cid:image001.png@01D2A950.442244A0]

James Gould
Distinguished Engineer
jgo...@verisign.com

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

VerisignInc.com

From: regext  on behalf of Pat Moroney 

Date: Thursday, March 30, 2017 at 12:10 PM
To: "Feher, Kal" , "regext@ietf.org" 
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  element 
like  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  
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 
mailto:kalman.fe...@neustar.biz>> 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).

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"
mailto:regext-boun...@ietf.org> on behalf of 
jkol...@godaddy.com> wrote:

>Alex wrote:
>
>>>
>No. Each fee involved would need to be equal or over the fee required by
>the server.
>>>
>
>Agreed.
>
>Thanks,
>Jody Kolker
>319-294-3933 (office)
>319-329-9805 (mobile) Please contact my direct 
>supervisor Charles
>Beadnall (cbeadn...@godaddy.com) 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:regext-boun...@ietf.org] 
>On Behalf Of Alexander
>Mayrhofer
>Sent: Wednesday, March 29, 2017 4:36 PM
>To: Thomas Corte mailto:thomas.co...@knipp.de>>; 
>regext@ietf.org
>Cc: supp...@tango-rs.com
>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.
>
>Yes. And i think it's good.
>
>> 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.
>
>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 che

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

2017-03-30 Thread Alexander Mayrhofer
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:regext-boun...@ietf.org] Im Auftrag von Gould, James
Gesendet: Donnerstag, 30. März 2017 12:22
An: Pat Moroney; Feher, Kal; regext@ietf.org
Betreff: Re: [regext] draft-ietf-regext-epp-fees [x_phishing]

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

[cid:image001.png@01D2A950.C27549B0]

James Gould
Distinguished Engineer
jgo...@verisign.com

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

VerisignInc.com

From: regext mailto:regext-boun...@ietf.org>> on 
behalf of Pat Moroney mailto:pmoro...@name.com>>
Date: Thursday, March 30, 2017 at 12:10 PM
To: "Feher, Kal" mailto:kalman.fe...@neustar.biz>>, 
"regext@ietf.org" 
mailto:regext@ietf.org>>
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  element 
like  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  
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 
mailto:kalman.fe...@neustar.biz>> 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).

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"
mailto:regext-boun...@ietf.org> on behalf of 
jkol...@godaddy.com> wrote:

>Alex wrote:
>
>>>
>No. Each fee involved would need to be equal or over the fee required by
>the server.
>>>
>
>Agreed.
>
>Thanks,
>Jody Kolker
>319-294-3933 (office)
>319-329-9805 (mobile) Please contact my direct 
>supervisor Charles
>Beadnall (cbeadn...@godaddy.com) 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:regext-boun...@ietf.org] 
>On Behalf Of Alexander
>Mayrhofer
>Sent: Wednesday, March 29, 2017 4:36 PM
>To: Thomas Corte mailto:thomas.co...@knipp.de>>; 
>regext@ietf.org
>Cc: supp...@tango-rs.com
>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.
>
>Yes. And i think it's good.
>
>> 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 overchargin

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

2017-03-30 Thread Feher, Kal
Agree.

Kal

From: Alexander Mayrhofer 
mailto:alexander.mayrho...@nic.at>>
Date: Thursday, 30 March 2017 at 12:25
To: "Gould, James" mailto:jgo...@verisign.com>>, Pat 
Moroney mailto:pmoro...@name.com>>, Kal Feher 
mailto:kalman.fe...@neustar.biz>>, 
"regext@ietf.org" 
mailto:regext@ietf.org>>
Subject: AW: [regext] draft-ietf-regext-epp-fees

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:regext-boun...@ietf.org] Im Auftrag von Gould, James
Gesendet: Donnerstag, 30. März 2017 12:22
An: Pat Moroney; Feher, Kal; regext@ietf.org
Betreff: Re: [regext] draft-ietf-regext-epp-fees [x_phishing]

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

[cid:image001.png@01D2A950.C27549B0]

James Gould
Distinguished Engineer
jgo...@verisign.com

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

VerisignInc.com

From: regext mailto:regext-boun...@ietf.org>> on 
behalf of Pat Moroney mailto:pmoro...@name.com>>
Date: Thursday, March 30, 2017 at 12:10 PM
To: "Feher, Kal" mailto:kalman.fe...@neustar.biz>>, 
"regext@ietf.org" 
mailto:regext@ietf.org>>
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  element 
like  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  
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 
mailto:kalman.fe...@neustar.biz>> 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).

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"
mailto:regext-boun...@ietf.org> on behalf of 
jkol...@godaddy.com> wrote:

>Alex wrote:
>
>>>
>No. Each fee involved would need to be equal or over the fee required by
>the server.
>>>
>
>Agreed.
>
>Thanks,
>Jody Kolker
>319-294-3933 (office)
>319-329-9805 (mobile) Please contact my direct 
>supervisor Charles
>Beadnall (cbeadn...@godaddy.com) 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:regext-boun...@ietf.org] 
>On Behalf Of Alexander
>Mayrhofer
>Sent: Wednesday, March 29, 2017 4:36 PM
>To: Thomas Corte mailto:thomas.co...

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

2017-03-30 Thread Hollenbeck, Scott
I agree, too.



Scott



From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Feher, Kal
Sent: Thursday, March 30, 2017 1:31 PM
To: regext@ietf.org
Subject: [EXTERNAL] Re: [regext] draft-ietf-regext-epp-fees



Agree.



Kal



From: Alexander Mayrhofer 
mailto:alexander.mayrho...@nic.at>>
Date: Thursday, 30 March 2017 at 12:25
To: "Gould, James" mailto:jgo...@verisign.com>>, Pat 
Moroney mailto:pmoro...@name.com>>, Kal Feher 
mailto:kalman.fe...@neustar.biz>>, 
"regext@ietf.org" 
mailto:regext@ietf.org>>
Subject: AW: [regext] draft-ietf-regext-epp-fees



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:regext-boun...@ietf.org] Im Auftrag von Gould, James
Gesendet: Donnerstag, 30. März 2017 12:22
An: Pat Moroney; Feher, Kal; regext@ietf.org
Betreff: Re: [regext] draft-ietf-regext-epp-fees [x_phishing]



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
jgo...@verisign.com

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

VerisignInc.com



From: regext mailto:regext-boun...@ietf.org>> on 
behalf of Pat Moroney mailto:pmoro...@name.com>>
Date: Thursday, March 30, 2017 at 12:10 PM
To: "Feher, Kal" mailto:kalman.fe...@neustar.biz>>, 
"regext@ietf.org" 
mailto:regext@ietf.org>>
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  element 
like  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  
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 
mailto:kalman.fe...@neustar.biz>> 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).

   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"
   mailto:regext-boun...@ietf.org> on behalf of 
jkol...@godaddy.com> wrote:

   >Alex wrote:
   >
   >>>
   >No. Each fee involved would need to be equal or over the fee required by
   >the server.
   >>>
   >
   >Agreed.
   >
   >Thanks,
   >Jody Kolker
   >319-294-3933 (office)
   >319-329-9805 (mobile) Please contact my direct 
supervisor Charles
   >Beadnall (cbeadn...@godaddy.com) 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 no