[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "'Klaus Malorny'" <Klaus.Malorny@knipp.de>
Cc: ietf-provreg@cafax.se
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Wed, 27 Jun 2001 08:44:46 -0400
Sender: owner-ietf-provreg@cafax.se
Subject: RE: Billing information and EPP/GRRP-REQ

Klaus,

I don't think I understand your suggestion.  It sounds like you'd like to
see a client-provided serial number and a client-provided credit/debit
amount related to registrar billing actions with their customers, but I
don't understand how that info is of any use or concern to a registry.

If I'm misreading what you wrote, are you instead talking about registry
billing of the registrar, for example letting the registrar know how much
credit they have left after adding or renewing a domain name?  If so,
wouldn't this be best done in registry-defined extensions to the protocol?

If I'm still completely off-base, can you provide some XML examples that
illustrate your suggestion?

<Scott/>

>-----Original Message-----
>From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de]
>Sent: Wednesday, June 27, 2001 8:32 AM
>To: Hollenbeck, Scott
>Cc: ietf-provreg@cafax.se
>Subject: Re: Billing information and EPP/GRRP-REQ
>
>
>"Hollenbeck, Scott" wrote:
>
>
>> I'd certainly prefer to keep registry-specific billing details out of the
>> protocol.  If they have to be in there anywhere a registry could do
whatever
>> it wants in the <unspec> elements.  If you have a proposal in mind,
though,
>> please post it to the list to present a more complete picture and to
gather
>> other opinions.
>> 
>> <Scott/>.
>
>
>Hi Scott,
>
>sorry for not answering earlier, but I'm quite busy these days, so I had
not
>much time.
>
>My original idea was to add some general accounting information to each
>request, at least a serial number (I would have called it transaction
number
>if there wouldn't be a chance to be confused with other transaction IDs)
and
>the amount either deducted or credited. The serial number is used to keep
>track/synchronize with invoices received by other means, i.e., not to book
a
>certain item twice. Well, additional fields could contain the account
number
>and a description field, which holds the cause of the posting.
>
>There is of course a problem: Some costs may be generated outside of the
>requests, e.g. a registry may decide to have an auto-renewal mechanism
(like
>the .DE registry on a monthly base), or the gaining registrar does not have
to
>pay the fees before the loosing registrar accepts the transfer. So there
may
>be no chance to report it immediately together with the response. One way
>would be to report these costs via a poll, but I fear that either the
number
>or the sizes of the responses could be too much. Another way would be to
keep
>the records at the registry and report them on the next request to the
object.
>
>Please let me add the following to the background of my questions: Many
>registrars have or will have resellers, and these resellers also may have
>resellers and so on. Due to bad experiences, many registrars and resellers
>require prepayment for bulk domain registrations. To keep track how much of
>the payed money has been eaten up, it would be helpful to have immediate
>feedback from the registry about the costs of a request and therefore be
able
>to block requests from a certain customer if necessary. Since a registrar
may
>bill his customers different to the way he is billed, it may also be
suitable
>to have more abstract accounting information, e.g. on a delete request:
"you
>have been charged for X registration periods".

Home | Date list | Subject list