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 sak
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 na
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
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)
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
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 exac
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
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"
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
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,
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"
mail
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>>
D
12 matches
Mail list logo
