Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!utcsri!utegc!rayan
From: rayan@utegc.UUCP
Newsgroups: can.general
Subject: How to run the UUCP interface to the CA domain authority?
Message-ID: <8710182343.AA13469@ephemeral.ai.toronto.edu>
Date: Sun, 18-Oct-87 19:44:07 EDT
Article-I.D.: ephemera.8710182343.AA13469
Posted: Sun Oct 18 19:44:07 1987
Date-Received: Sun, 18-Oct-87 22:35:33 EDT
Distribution: can
Organization: University of Toronto, AI group
Lines: 204
Checksum: 31948

[ Warning: This message is 10k, all of it prose. Grab some warm chocolate... ]

As part of the domain registration application documents (what a
mouthful!), there will be a list of contact points for submitting the
applications. The way this is intended to work, is that there will be a
central location that acts as a clearing house (the CA domain
authority) and each network will provide a liaison function for its
members. The CA domain authority will be CDNNET headquarters for now,
although in the long run this will probably move to a government body
of some sort (e.g. NRC). Having such a central clearing house is
necessary for concurrency control, to act as the authority in case of
problems, and to coordinate dissemination of routing data. The point of
encouraging interaction through a network-specific mechanism is to
decrease the load on the CA authority, and allows each network to cater
to its needs and procedures. For example, in the UUCP world it would be
advantageous to coordinate between the domain registry and the UUCP map
data.  In other networks, they have their own routing data formats and
procedures for maintaining the data.

The purpose of this message is to start a bit of discussion (in private
mail if people wish) about how we should set up this liaison function
in the Canadian UUCP community. In the very short term, what I need to
come up with is an E-mail and (Paper) post address as the UUCP contact
point for submitting domain registration applications. Beyond that,
nothing is decided until there appears a consensus of what to do.

By way of background, I should mention that the functionality
envisioned is something similar to the UUCP Zone in the U.S., which
interfaces with the DDN NIC (Defense Data Network, Network Information
Center) for all UUCP sites wishing to register a domain under the
.COM/.EDU/.GOV/... toplevel domains, which cannot do it themselves by
virtue of being on the ARPA/NSF Internet.  In our case, CDNNET HQ is
the analogue of the DDN NIC. There is a provision for unaffiliated
(with a network) organizations of registering directly with CDNNET HQ
for a yearly fee (planned to be 50$ or so). CDNNET will liaison (with itself :-)
for its members, at no additional cost to them, and NetNorth will do the
same I believe.

I should also clarify the situation regarding personal/private sites.
The CA authority does not want to register individuals' home PC at this
time.  The intent for such sites is that they either gather together in
associations (or clubs, etc.) which can register a domain, or hang off
of registered domains using existing addressing kluges. The only way to
integrate such sites would be through kluges in the domain hierarchy,
which is deemed undesirable. The problem of assigning electronic
addresses to individuals (independent of location) is something that
will become more acute in the next few years, but it is not one we can
solve. (It is a global problem and needs to be addressed (hmm,
unintentional pun there...) by globally adhered-to standards.)

Now, there are several matters to be settled:

1. How can we do it?

There are several possibilities I can think of... let me list them:

	a- we don't do it at all, and everyone just goes straight to CDNNET HQ.
	b- we use the existing mechanism of the U.S. UUCP Zone.
	c- we use an existing Canadian Unix organization (/usr/group/cdn).
	d- we set up our own formal organization (incorporate'n all) to do it.
	e- we get the Canadian UUCP Map coordinator(s) to do it.
	f- we set up a good basis from which we can wing it.

I will comment on all of them (so you can see why I'd prefer f), but first let
me mention some criteria I'd like to see fulfilled:

	- continuity of service (this relates to fees, to be discussed below)
	- a certain level of technical competence
	- a certain level of accountibility to the UUCP community in terms
	  of activity and use of fees.

So, my commentary:

a-	I'm not at all sure they'll like that, in fact probably the opposite.
	It'd also severely complicate the little matter of getting good routing
	data for the .CA domains into the maps. Not to mention reflect poorly
	on our self-esteem.
b-	This is a possibility, since they (in the person of Mark Horton) have
	expressed a willingness to help/coordinate in such matters, subject to
	negotiations. There are disadvantages in that they don't have much of an
	incentive, and that we wouldn't have much (any) control over how things
	are run. Besides this there may be administrative difficulties of
	various kinds (e.g. connectivity and interaction with CA authority,
	currency problems, and it being a U.S. organization). There has been
	a certain amount of griping at the handwaving Mark did when asked to
	explain what the UUCP Zone fees were going to.
c-	Not to slight any such organizations, but if (and where) they exist
	they seem to have a different focus than to provide this kind of
	service (at least from what I've seen). It would probably be premature
	to rely on them for our purposes.
d-	This is probably what should happen eventually in some form, to look
	after the interests of the Canadian UUCP community vis-a-vis all the
	things that are happening that will affect us. However, I don't think
	we are ready for such structure as yet. This is a possible evolution
	for /usr/group/cdn and/or whatever we come up with now.
e-	I'm it, and its a thankless enough volunteer job as it is. This would
	be ideal from the point of view of coordinating with the UUCP map.
	Personally, I think I've put a lot of time in over the last 3 years
	to the community benefit, and I'm not happy about adding to the load
	merely "out of the goodness of my heart".
f-	"winging it" is perhaps a misnomer in this connection; what I mean is
	there isn't a real formal organization to actually do the work. This
	message is slightly delayed because I wanted to investigate what kind
	of local infrastructure support could be made available to our project.
	It appears the local powers are willing to lend a hand in this, as I
	shall describe below.

The following elements are necessary to run a liaison function as intended:

- someone to do the work.
- a computer account to do it in/from.
- a mail drop (paper mail) for letters containing fees.
- administrative support to process fees and manage the monies in an account.

I asked the director of the Computer Systems Research Institute here
about this matter, and to which degree they could help. They are (and
very gracious of them, I might add) willing to set up an account,
provide a mail drop, and set up and manage money account(s) and process
fees as long as the volume remains reasonable ("a couple of hundred
checks a year or so"). The computer account, labour, and any
administrative costs would be paid for out of the fees. They are aware
this is a community service item, and therefore administrative costs to
us would be 0 as long as the load is reasonable. As well, the computer account
would be charged at some factor (as yet unknown, but low) above that used
for primary research users around here. It is understood that for now I
would provide most of the labour, but there will be continuity should I
leave or keel over dead (which probably means I'll be training local staff
once things become routine and/or I get tired of it).

This takes care of the operational side of things, the remaining item is:

2. Fees.

Why have fees at all? Several reasons:

- It costs money to store, maintain, and disseminate the necessary data.
  If not directly, then certainly indirectly in hidden or opportunity costs.
- To ensure continuity, it is necessary to ensure that running or sponsoring
  such a service is not a losing proposition, neither directly in financial
  terms, nor in (my fav. phrase) opportunity cost.
- To ensure proper procedures are followed in the applying organizations.
- As a nuisance fee to keep the crackpots away.

I don't think it is realistic to NOT have a fee for these reasons.

Assuming we do have a fee, what should it be? Well, it should at least
cover expenses, i.e. computer account, labour, and any administrative expenses.
Estimating these figures is very hard to do due to lack of experience.
I'll take a rough stab at it here:

computer account:
say disk usage of 30k per subdomain. This covers the variable usage for:
original application form, munged ditto, corresponding map entries for the
subdomain (different from normal UUCP link info), and storing correspondence
with the subdomain and with the CA registrar about the subdomain.
In addition, this includes a share of the storage needed for maintenance
programs and various other data (pathalias databases, log files, etc.),
which depends on how many registrations are handled.

cpu time? I don't really know... the UUCP map maintenance account takes
a couple of cpu hours, on average, per month on a VAX780. I'd guess
somewhere between 5 and 10 cpu minutes per subdomain while it is being
registered, and a few seconds per month after that.

Assuming we'll be charged at a factor 2 over minimum rates, the computer
account charges will be approx:

2 * (0.2 * 22$/hr cpu + 12*30*2 * 0.0085 $/blk-mon) = 2 * 10.52 = 21$/year.

For comparison, applying commercial rates on the CSRI machines would make
it a factor of 12 instead of 2.

labour:
Assuming an hourly rate of 25$, and somewhere between 10 and 30 minutes spent
in total per subdomain (the actual time depends on a lot of things, primarily
the complexity of the site), that gives approx. 25/3 = 8$. This could be
paid as some factor (1.1 or so) times the session time on the computer account,
at some hourly rate. The factor is intended to take into account any
non-electronic activities.

Administrative costs and other expenses cannot be estimated. Their total
will probably be non-zero, but cost/subdomain should be negligible.

So, in total, with estimates that may seem a bit on the high side, the total
cost per year is on the order of 30$ per subdomain. Therefore I suggest the
fee be set at 30$/year <= fee <= 50$/year.


Soo, to conclude this very long message, my proposal is:

We make use of CSRI facilities to provide the necessary computer and
administrative support (and postal drops, etc.). For now, I'll coordinate
things with the UUCP community, CSRI, and the CA authority, until the
need or desire arises to pass on the operation to someone else trained in
doing it. The yearly fee shall be X$ (what do you think X should be?),
and will be managed by the local burearcracy (e.g. checks would have to
be made payable to UofT, but end up in an account set up for the purpose).
The fee money will be used to pay expenses as outlined above.
If it turns out after a year or so that the fee is too high or low, we can
readjust it then (to avoid problems, I think it is better to start out with
a high fee).

Comments invited.

rayan