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: ..K12..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..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 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 ..K12..US and public schools are registered by ..K12..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 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 ------------------------------