[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Preparing to issue invoices (was: Introducing Pat Kane)
- Niall O'Reilly
- Subject: Preparing to issue invoices (was: Introducing Pat Kane)
- Date: Fri, 18 Oct 1996 10:55:55 +0000
On 17 Oct 96 at 14:28, denis@removed wrote:
> Congratulations on the hiring of staff. We have yet to
> recieve a list of the domains for which we are responsible on
> the invoice front. Most of these domains are only used for email
> and have been registered by us. Can someone please contact me on
> this. There are a very small number of domains involved.
I'm glad you asked that question. I'm taking the opportunity to copy
the answer to the IEDR-Forum list, as I expect the information will
be generally useful.
Our plan for issuing invoices is the following.
- Take frozen copy of registration data file. [done 30 Sep 96]
- Create draft schedule of domains for each [18 Oct 96]
- Present each draft schedule to corresponding [18-23 Oct 95]
billing contact, obtain and apply corrections,
repeating until schedule is finalised.
- Issue invoice based on finalised schedule. [25 Oct 96]
In September, we made an initial distribution of draft schedules and
received a number of corrections. I'ld like to thank again those
people who advised us of errors.
We shall now make a new distribution of draft schedules. I expect
that there will still be errors, due to any of the following causes:
- missing information as to billing contact;
- incorrect inference of billing contact from zone data;
- failure to propagate recent updates in live data to
copy used for generating schedules;
- misunderstanding as to willingness of provider to act
as billing contact for any or all client domains.
Historically, we have not taken account in our registration
procedures of the need to support a billing activity. Consequently
we have had to infer a supposed billing contact from available data.
The most convenient data for this purpose was to be found in the
NS and MX records in the zone file, as every domain must have either
one or other kind of record, and server host names could in most
cases be identified with service providers.
Use of NS and MX records for this purpose can obviously lead to
errors where a number of providers have mutual arrangements for
secondary name servers: the server name used to make the inference
may be the wrong one. In particular, this may lead to all of the
domains served by a particular provider being erroneously identified
as related to a different provider.
If you expect to receive a draft schedule now and don't, or expected
to receive one in September in the earlier distribution and didn't,
please let us know. The most likely reason is that our data and our
procedure for generating the schedules didn't allow us to find any
domains for which you could be identified as service provider.
When letting us know this, it will be most useful if you will also
advise us of the domains for which you understand you are the provider.
I count on participation and understanding from all of you in this
IE Domain Registry
University College Dublin Computing Services