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