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

------------------------------

