File Utahstd.txt July 1994
The two documents included in this file constitute the State of Utah
naming and numbering standard for Novell objects. The system has been in
wide use for several years with no difficulties.
In simplest terms, the first standard says use Internet names and
numbers for Novell objects, with slight modification. Novell numbers are
Internet numbers, but expressed in hexadecimal notation. IPX network numbers
are IP network numbers; the IPX internal network number of a file server is
the IP address of the interface closest to the main backbone. Novell names
are IP names, but in reverse order of phrases and with dashes replacing
dots. Underscores are forbidden because NetWare 4 treats them as spaces.
The second document says Utah adopts IP naming conventions of
RFC 1280 regarding public schools (K-12).
Joe Doupnik
Dept of Electrical Engineering
Utah State University
Logan, Utah 84322
(801) 797-2982 voice, -2992 fax
jrd@cc.usu.edu
-------------------
David Hoisve and Joe Doupnik. Approved February 7, 1992
Revised: ITS Naming conventions. Draft April 27, 1994
Marked up draft Revised: ITS Naming conventions. Draft April 29, 1994
Accepted: 29 April 1994
Utah Education Network
Novell IPX Network Number
and Novell SAP Service Naming Standard
Novell Service Naming Standards
The following Novell Service Naming Standard uses Internet domain
names or IP addresses as the basis for naming Novell services. This
mechanism is a means to assign Novell Service Names based on an existing
mechanism which will guarantee unique names within the Utah Education
Network and with compatible external organizations. By design, this
standard is equally useful to other regions in the world; and such regions
might interconnect successfuly without interference.
Novell "Services" are text names for services provided on a Novell
network. Service names are broadcast using Novell's Service Advertising
Protocol (SAP).
Standard 1: Novell Service Names
All Novell Service names broadcast from the object which reach
outside the parent organization to the Utah Education Network must start
with the organization's assigned Internet domain and subdomain names,
with fields separated by dashes.
For example, the University of Utah is assigned the subdomain UTAH
in domain EDU (at UofU all Internet names end with UTAH.EDU). All Novell
Services broadcast by the University of Utah on the Utah Education Network
must start with EDU-UTAH-.
Note that aside from this requirement, service names may be
determined by the organization. This is a direct copy of assignment by the
Internet authorities of Internet names and numbers as a globally unique
portion and a locally selected portion.
Standard 2: Short Service Names
Some Novell-compatible Named Services limit the length of service
names. In this case, it is permissible to use the text form of the
hexadecimal numeric IP address assigned to the server or system providing
the service.
For example, if 128.110.48.64 were assigned to a gateway, we could
use "806E3040_GW" as the service name. If necessary, the "_GW" could be
omitted.
Standard 3: Vendor-Supplied Service Names
Some Novell-compatible products use vendor-supplied service names.
Many of these names contain product information or serial numbers. These
names are permissible on the network provided that the connecting
organization obtains approval from the Utah Education Network Standards
Committee. In general, the request will be approved if there is a need to
broadcast the SAP for the service, the names are unique and do not
conflict with any other service on the network, and that the service name
is associated with an IPX network address.
Standard 4: Utah State Government Service Names
Service names originating from non-academic Utah State Government
sites may follow the service name standard established for the State
Information Technology Services Wide Area Network. Under this standard,
all service names start with "UTST" and are generally limited to 8
characters. This standard is nonconflicting and interoperable with the
other standards in this document.
It is to be realized that this is an exception to the general
principle of basing names on globally unique Internet names, and thus
the UTST names may not be able to be routed to more distant locations
in the future. Non-routing is to ensure absence of conflicts at remote
sites and beyond.
Standard 5: Non-compliant Service Names.
Service names that do not comply with Standard 1-3 must be
approved by the Utah Education Network Standards Committee.
Novell IPX Network Numbering Standards
The following Novell IPX Network Numbering Standard uses IP (Internet
Protocol) numerical address assignments as the basis for Novell IPX
Network numbers. Uniqueness is again guaranteed by the Internet
authorities for IP numbers, and the Novell IPX network (and node) numbers
are the same values. Novell numbers are characteristically written as
hexadecimal text strings, similar to dotted decimal IP strings. It should
be noted that packets of the two protocols (IP and IPX) are totally
independent and thus there is no confusion about the same address values
being used by two or more protocols.
Standard 1: Novell IPX Networks.
All Novell Network Numbers (including IPX Internal Network numbers
and IPX LAN addresses) will start with the hexadecimal equivalent of the
unique portion of the organization's assigned Internet address. It is
strongly recommended, but not required, that a complete IP address be
assigned to such objects and that the complete IP address value be used
as the Novell numericial identification.
For example, if the organization were assigned an Internet "Class
C" address of 192.110.48.?, all IPX Network Numbers must start with
C06E30??. In this case the last octet of the address is assigned by
the organization to various local objects.
If an organization were assigned the "Class B" address of
129.123.?.?, all IPX Network Numbers must start with 818B????. The last
two octets of the address are assigned by the organization.
Standard 2: Non-compliant IPX Network Addresses.
IPX Network addresses not in compliance with Standard 1 must be
approved by the Utah Education Network Standards Committee.
Motivation
The goal of this set of standards is to specify a method of
assigning both names and numbers to NetWare objects so that systems may be
connected together in the future in ways unexpected presently, and such
interconnections will not require adjustments to running NetWare systems
nor create significant administrative effort. The system should also
produce identifications easily recognizable by people.
NetWare requires that all objects advertizing their presence have a
unique name and number. Discovering conflicting network names and numbers
is a difficult process and while the conflicts exist network operations
may be confused in certain regions. Adding connections beyond the current
areas are to be expected in the future, and renaming operating
environments can become increasingly difficult. Selection of nic-names,
telephone numbers, Zip codes, and other everyday items does not guarantee
uniqueness over large areas, particularly when crossing national
boundaries.
Further, tasking a committee with approving names and numbers is
beyond the limited resources of the member institutions. It is doubtful
whether wider connectivity could be supported by such part time committee
action.
One system does exist world wide to assign names and numbers to
networking entities: the Internet. Network nodes are grouped into domains
and subdomains and a subdomain identification can be issued with range of
network numbers and names. The Internet authorities will guarantee there
will be no duplication of a complete name in other subdomains. Within
the assigned subdomain extra fields are assigned locally. Thus the
Internet authorities are used to administer the division of names and
numbers, and the local organization is free to add the local
identification components. As added benefit computer systems are now
organized to provide routing of information based on these quantities.
By happy coincidence the size of an Internet address is the same as
a Novell Network address: 4 octets, 32 bits. Thus there can be one to one
mapping between them. Octets could have been expressed in either Internet
(big endian) or reversed (little endian) order; this standard specifies
them to be the same order as written for the Internet: globally assigned
then the local part, left to right.
Internet names are typically written with periods (dots) separating
components. While this notation has become familiar to most network users
Novell currently does not permit dots in the names of NetWare objects.
Thus we specify a hyphen (dash) as a natural replacement for a dot, and
this is acceptable to both ASCII and EBCDIC based computers. Underscores
are equivalent to spaces for NetWare 4 systems and are to be avoided
because of the ambiguous parsing which results from embedded spaces. The
character set is a subset of ASCII: letters and numbers and the hyphen,
case insensitive. Names must not terminate with a hyphen.
To facilitate grouping of names on displays and in programs,
particularly when the number of interconnected systems increases greatly,
an alphabetical ordering is desirable. This works best if the ordering is
from global to local. Thus educational institutions use names starting
with EDU-, commercial ones with COM-, government with GOV-, and so on. The
NetWare name becomes the Internet name reversed left to right. As an
example of use, consider asking to see all the names at one institution,
Utah State Univ, EDU-USU-. We can express this as EDU-USU-*, meaning all
ending suffixes. Or, EDU-U* for all machines with that prefix, such as
EDU-UTAH- and EDU-USU-. The reverse use of wild cards is not supported by
DOS: *-USU-EDU expands to mean all names whatsoever. Naturally,
geographically based names from the Internet are ordered similarly.
Deficiencies
At first reading the placement of global name components first seems
to preclude shorthand names for local systems. In practice people use full
names for Email addresses and there are no complaints. Also most people
login or attach to NetWare servers via Batch files and do so once per day.
Thus Internet style names for NetWare objects is no more burden than
sending a mail message.
Vendors need to be aware that NetWare names are limited to about 48
characters overall and the vendor specific part needs to be short enough
to permit unique identification. Thus a product choosing a name such as
"PRODUCT-local" needs to keep "PRODUCT" short enough to let "local"
encompass a unique local name. The same is true for choosing local names;
keep them reasonable short.
The existence of non-compliant names and or numbers imposes a burden
upon all systems, connected now or in the future. Special steps are
required in configuring routers between sites such that these objects are
known to the smallest possible region. Use of such identification is
strongly discouraged, may not be done without approval of the oversight
body, and yet such an escape is necessary if experimental configurations
or new products are to be tested.
The standard does not address the issue of which objects shall be
advertized from a site and which shall be accepted if arriving from
outside. Advertizing all local resources burdens networks with unnecessary
traffic and adds unwanted information to local programs. Accepting all
advertisements can expose a site to unexpected conflicts for a short
period of time. We feel these selections should be done by each site
individually, with consideration for minimizing the global transfers. The
quantity of information will grow over time as more diverse services
become required by each client workstation and the hope is network
bandwidth and service advertizing algorithms will adjust to the demand. In
the meanwhile master routers should be configured to minimize unnecessary
traffic traveling in both directions; this can be done by reducing the
advertizing rate as well as blocking purely local items such as printer
and modem servers.
Other standards
Novell has created a Novell Registry office to act as a clearing
house for names and numbers of NetWare objects. We have consulted with
Novell on this current standard and the Novell Registry, hoping that the
two could be melded into a unified naming space. The Registry uses the
same standard as above for assigning names to objects. However, the
numerical identifications may differ if the organization chooses to not
obtain an Internet address. Novell's Registry essentially draws from
unused Internet Class A network 0.-.-.-. It is the view of the UEN
Standards Committee and Novell that should a numerical conflict ever arise
then we will find a suitable workaround.
(end of document)
=======================================================================
Draft: April 26, 1994
Minor edit: April 29, 1994
Adopted: April 29, 1994
Public Education Naming Standard
Utah Education Network
April 29, 1994
The Utah Education Network supports RFC 1480 which suggests
that K-12 institutions use the US domain for IP name services. The
University of Utah Computer Center (UUCC) has applied for, and
received, the K12.UT.US domain name. UUCC has agreed to
administer this domain another party agrees to take over this
responsibility.
Therefore, following RFC 1480, it is recommended that public
school districts apply for a subdomain in the domain K12.UT.US. For
example, the Iron County School District Office might apply for the
name IRON.K12.UT.US. The district could administer the
IRON.K12.UT.US domain or request another party to administer the
domain until the district is prepared to provide name services directly.
Note that some domain names may become long. RFC 1480
suggests there may be appropriate abbreviations that can be used in
these instances. This kind of decision will generally be made by the
public school district, noting that abbreviations can make it difficult to
remember and associate the names with the places.
Following is an excerpt from RFC 1480. Several general
examples throughout this excerpt. Specific examples for the
K12.UT.US domain appear at the end of this document.
[Start of The US Domain Excerpt]
Network Working Group A. Cooper
Request for Comments: 1480 J. Postel
Obsoletes: 1386 June 1993
The US Domain [EXCERPT]
2.3 Schools
K12 schools are connecting to the Internet and registering in the
Internet DNS. A decision has been made by the IANA (after
consultation with the new InterNIC Internet Registry and the Federal
Networking Council (FNC)) to direct these school registrations to the
US domain using the naming structure described here.
There is a need for competent, experienced, volunteers to come
forward to act as third and perhaps fourth level registries and to
operate delegated portions of the DNS.
There are two reasons for registering schools in the US Domain. (1)
uniqueness of names, and (2) management of the database.
1. Name Uniqueness:
There are many "Washington" high schools, only one can be
"Washington.EDU" (actually none can be, since that name is used
by a University. There will be many name conflicts if all
schools attempt to register directly under EDU.
In addition, in some districts, the same school name is used at
different levels, for example, Washington Elementary School and
Washington High School. We suggest that when necessary, the
keywords "Elementary", "Middle", and "High" be used to
distinguish these schools. These keywords would only be used
when they are needed, if the school's name is unique without
such keywords, don't use them.
2. Database Management:
One goal of the DNS is to divide up the management of the name
database in to small pieces. Each piece (or "zone" in DNS
terminology) could be managed by a distinct administrator.
Adding all the high schools to the EDU domain will make the
already large zone file for EDU even larger, possibly to the
point of being unmanageable.
For both these reasons it is necessary to introduce structure into
names. Structure provides a basis for making common names unique in
context, and for dividing the management responsibility.
The US Domain has a framework established and has registered many
schools already in this structured scheme. The general form is:
<school>.<district>.K12.<state>.US.
For example: Hamilton.LA-Unified.K12.CA.US
Public schools are usually organized by districts which can be larger
or smaller than a city or county. For example, the Portland school
district in Oregon, is in three or four counties. Each of those
counties also has non-Portland districts.
It makes sense to name schools within districts. However districts
often have the same name as a city or county so there has to be a way
to distinguish a public school district name from some other type of
locality name. The keyword "K12" is used for this.
For example, typical K12 school names currently used are:
IVY.PRS.K12.NJ.US
DMHS.JCPS.K12.KY.US
OHS.EUNION.K12.CA.US
BOHS.BREA.K12.CA.US
These names are generally longer than the old alternative of shorter
names in the EDU domain, but that would not have lasted long without
a significant number of schools finding that their "obviously
correct" name has already been used by some other school.
When there are many things to name some of the names will be long.
In some cases there may be appropriate abbreviations that can be
used. For example Hamilton High School in Los Angeles could be:
Hami.Hi.LA.K12.CA.US
If a school has a number of PCs, then each PC should have a name.
Suppose they are named "alpha", "beta", ... then if they belong to a
school named "Lincoln.High.Lakewood.K12.CA.US" their names would be:
alpha.Lincoln.High.Lakewood.K12.CA.US.
beta.Lincoln.High.Lakewood.K12.CA.US
...
The K12 subdomain provides two points at which to delegate a branch
of the database to distinct administrators -- the K12 Administrator
for each state, and the district administrator for each district
within a state.
The US Domain Administrator will delegate a branch of the US domain
to an appropriate party. In some cases, this may be a particular
school, a school district, or ever all of K12 for a state.
The responsibility for managing a K12 branch or sub-branch may be
delegated to an appropriate volunteer. We envision that such
delegations of the schools' DNS service may eventually migrate to
someone else "more appropriate" from an administrative organizational
point of view. The "obvious" state agency to manage the schools' DNS
branch may take some time to get up to speed on Internetting. In the
meantime, we can have the more advanced schools up and running.
Special Schools and Service Units
In many states, there are special schools that are not in districts
that are run directly by the state or by consortiums. There are also
service units that provide "educational services" ranging from books
and computers to janitorial supplies and building maintenance. Often
these service units do not have a one-to-one relationship with
districts.
There is some concern about naming these schools and service units
within the naming structure for schools established in this memo.
There are several possibilities. For a state with many service units
creating a "pseudo district" ESU (or whatever, the common terminology
is in that state) is a possibility. For example, the Johnson service
unit could be JOHNSON.ESU.K12.CA.US. For a state with a few such
service units (and avoiding conflicts with district names) the
service units could be directly under K12. For example,
TIES.K12.MN.US.
The special public funded schools can be handled in a similar
fashion. If there are many special schools in a state, a "pseudo
district" should be established and all the special schools listed
under it. For example, suppose there is a "pseudo district" in
Massachusetts called SPCL, and there is a special school called the
Progressive Computer Institute, then that school could have the name
PCI.SPCL.K12.MA.US. If there are only a few special schools, they
can be listed directly under K12 (avoiding name conflicts with
district names). For example, the California Academy of Math and
Science is CAMS.K12.CA.US. CAMS is sponsored by seven schools, the
California Department of Education, and a University.
"PVT" Private Schools
Private schools may be thought of as businesses. Public schools are
in districts, and districts provide a natural organizational
structure for naming and delegation. For private schools there are
no districts and they really do operate like businesses. But, many
people are upset to think about their children in a private school
being in a business category and not in K12 with the rest of the
children. To accommodate both public and private schools, in each
state's K12 branch, we've added an artificial district called private
or "PVT". This gives a private school the option of registering like
a business under "locality" or in the PVT.K12.<state-code>.US branch.
For example:
Crossroads.PVT.K12.CA.US
Crossroads-Santa-Monica.CA.US
A public school "Oak High" in the "Woodward" school district in
California would have a name like "Oak-High.Woodward.K12.CA.US".
A private school "Old Trail" in Pasadena, California could have the
<locality> based name "Old-Trail.Pasadena.CA.US" or the private
school base name "Old-Trail.PVT.K12.CA.US".
Some suggest that for private schools instead of a special pseudo
district PVT to use a locality name. One reason to use district
names is that, in time, it seems likely that school district
administrators will take over the operation of the DNS for their
district. One needs to be able to delegate at that branch point.
One implication of delegation is that the delegatee is now in charge
of a chunk of the name space and will be registering new names. To
keep names unique one can't have two different people registering new
things below identically named branches.
For example, if there is a school district named Pasadena and a city
named Pasadena, the branch of the name space PASADENA.K12.CA.US might
be delegated to the administrator of that public school district. If
a private school in Pasadena wanted to be registered in the DNS, it
would have to get the public school district administrator to do it
(perhaps unlikely) or not be in the K12 branch at all (unless there
is the PVT pseudo district).
So, if private schools are registered by
<school>.<locality>.K12.<state-code>.US and public schools are
registered by <school>.<district>.K12.<state-code>.US, there can't be
any locality names that are the same as district names or the
delegation of these will get very tricky later.
If it is all done by locality names rather than district names, and
public and private schools are mixed together, then finding an
appropriate party to delegate the locality to may be difficult.
Another suggestion was that private schools be registered directly
under K12, while public schools must be under a district under K12.
This would require the operator of the K12 branch to register all
districts and private schools himself (checking for name uniqueness),
he couldn't easily delegate the registration of the private schools
to anyone else.
[End of The US Domain Excerpt]
EXAMPLES OF UTAH SCHOOL NAMES
Here are some possible names for a high school named Pineview in the
Washington School District in Utah:
PineviewHS.Washington.K12.UT.US <== long, fairly obvious
Pineview.High.Washington.K12.UT.US <== long, fairly obvious
Pineview.High.Wash.K12.UT.US <== a little bit shorter
PVHS.Wash.K12.UT.US <== shorter, but obvious?
PVHS.WSD.K12.UT.US <== cryptic
Several steps are completed before a device at Pineview High School
can be assigned a name. First, a district domain name is chosen. Second,
the high school domain name is chosen. Finally, devices can be named.
Let's assume that the District and Schools have worked together to arrive
at the following:
District Domain Name Wash.K12.UT.US
High School Domain Name Pineview.High.Wash.K12.UT.US
Notice that the selection of Pineview.High for the high school name
is inserted to the left of the Wash.K12.UT.US district domain name. This
can be described by saying that the Pineview.High sub-domain is "inside"
the Wash.K12.UT.US domain.
Note: Once the district domain name is selected, it is generally not
acceptable for a district entity to reside "outside" the district
domain. For example, if Wash.K12.UT.US is the district domain
name, Pineview.High.K12.UT.US and Pineview.High.Washington.K12.US
are two examples that violate this rule.
Below are some example device names assuming a domain name of
Pineview.High.Wash.K12.UT.US:
SJones.Pineview.High.Wash.K12.UT.US <== Computer for Teacher
Sam Jones
LabFS.Pineview.High.Wash.K12.UT.US <== Lab File Server
LabPC1.Pineview.High.Wash.K12.UT.US <== Lab Computer
(end of document)
------------------------------
Date: Fri, 15 Dec 1995 16:07:24 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Questions on the UTAH standard
>I am trying to devise Netware IPX Naming and Numbering Standards
>for our campus. There are some issues that I need help with.
>
>Using the UTAH standard I am limited to a single IPX frame type? y/n
>For example; if I had Ethernet_II bound to IPX as well as 802.2 in
>the same fileserver. What would the External Net Number be for
>both frame types ?
I think that's my queue.
Each IPX frame type constitutes a different IPX network.
Running IPX with different frames over the same wire is discouraged
because it adds to routing traffic and is easily avoided by modernizing
nodes on the net.
If you are absolutely stuck with duplication of this kind then
choose one frame kind, say Ethernet_II, as the primary which gets the
regular Utah Standard numbering convention, and the other frame kind
is numbered as a host member (in IP-speak) of that net. Please see the
note subnets.txt on netlab2.usu.edu, in directory misc). The example
illustrates this situation where Ethernet_II is used for everything
except the remote boot ROMs which need Ethernet_802.3.
>In the UTAH naming standard our server names would be like the
>following:
>
>US-CA-CC-CUESTA-SQUID
>
>Squid being the server name, and cuesta.cc.ca.us being our domain
>suffix. Isn't this getting quite long for a Netware server name?
Nope. Not really in practice. Do you tire of typing Email addresses?
It was Email tolerance which led me to decide that full names were much less
painful than imagined, and NW names are typed far less often than Email
addresses. The idea is guaranteed uniqueness, forever. Shortcuts cannot make
that guarantee. Here is an abbreviated list seen by my desktop as I write this
note:
Known NetWare File Servers Network Node Address Status
-------------------------- ------- ------------ ------
EDU-SLCC-CS-DESTROYER [90230AA2][ 1]
EDU-SLCC-CS-DOMINO [90230A9C][ 1]
EDU-SLCC-CS-TERMINATOR [90230A96][ 1]
EDU-USU-ACENET-MOAB [817BA801][ 1]
EDU-USU-ADMISSIONS [817B41C7][ 1]
EDU-USU-AGLAB [817B0D53][ 1]
EDU-USU-AGX [817B01BA][ 1]
EDU-USU-B202 [817B1305][ 1]
EDU-USU-BRIGHAM [817BA101][ 1]
EDU-USU-CEE-LAB [817B081A][ 1]
EDU-USU-CPLACE [817B4F03][ 1]
EDU-USU-CS-CERBERUS [817B0732][ 1]
EDU-USU-CS-CWIS [817B07C4][ 1]
EDU-USU-CS-FACULTY [817B0726][ 1]
EDU-USU-ED-FS1 [817B3501][ 1]
EDU-USU-EHS [817B3A16][ 1]
EDU-USU-ENGINEERING [817B1507][ 1]
EDU-USU-ENGRLAB [817B0421][ 1]
EDU-USU-ERTC [817B3540][ 1]
EDU-USU-LIB-LIBLAB [817B0F07][ 1]
EDU-USU-LIB-LIBRARY [817B0F04][ 1]
EDU-USU-LIB-REF [817B0FCD][ 1]
EDU-USU-LIB-SCITECH [817B69ED][ 1]
EDU-USU-NETLAB2 [817B012C][ 1]Default
EDU-USU-NETLAB3 [817B014A][ 1]
EDU-USU-NETLAB4 [817B012E][ 1]
EDU-USU-NFSFS1 [817B2001][ 1]
EDU-USU-PURCHASING [817B3A03][ 1]
EDU-USU-RELATIONS [817B01AE][ 1]
EDU-USU-SDL-JOCC [817BC1DD][ 1]
EDU-USU-SDL-RPARK [817BBD65][ 1]
EDU-USU-SDL-SYSDIV [817BBD64][ 1]
EDU-UTAH-CC-UUSERV [806E3074][ 1]
EDU-UTAH-MED-ECCLAB [806E4E63][ 1]
EDU-UTAH-MEDIA-EDNET [9B633D7C][ 1]
EDU-WCSLC-SNAKEWATER [92560107][ 1]
EDU-WCSLC-WHITEWATER [92560103][ 1]
US-UT-K12-BOXELDER-PV [CD792702][ 1]
US-UT-K12-CACHE-CCSD [C63C3501][ 1]
US-UT-K12-CACHE-MCHS-FS2 [C63C31FC][ 1]
US-UT-K12-CACHE-MCHS-MCADM [C63C31FB][ 1]
US-UT-K12-CACHE-MCHS5 [C63C31FA][ 1]
US-UT-K12-CACHE-SVHS-IBM95 [C63C2DFD][ 1]
>Last but not least: Is it possible to have ethernet_II and
>token-ring_SNAP on a 100vg Anylan Network Simultaneously. (I'm not
>asking if its a bright idea, just if it's possible)
Nope, impossible. Ethernet is one media, Token Ring is a separate
media. They are electrically vastly different. VGAnyLAN is Ethernet flavor,
not Token Ring flavor.
>Donovan Bray Internet email: dbray@bass.cuesta.cc.ca.us
>Network Technician Voice: (805) 546-3248 Fax: (805) 546-3102
>Cuesta College P.O. Box 8106, San Luis Obispo, CA 93403-8106
------------------------------