UGA Domain Network Liaison Handbook

Enterprise IT Services
Computer Services Annex
University of Georgia
Athens, GA 30602-1911
(last updated 2005-03-04)


1. Overview of UGA Network Support Infrastructure
1.1 Central Network Support Responsibilities
1.1.1 NOC Responsibilities
1.1.2 NIC Responsibilities
1.2 Network Domain Support Responsibilities
2. Network Information Management
2.1 Network Interface Card Information
2.2 IP Information
2.2.1 IP Addresses and Domain Names
2.2.2 LPD Server Registration
2.3 IPX Information
2.4 AppleTalk Information
3. Network Problem Resolution
4. Network Notification
5. DNL Changes

1. Overview of UGA Network Support Infrastructure

The UGA campus network consists of the hardware and software resources necessary for the exchange of digital information in a distributed computing environment; it also represents the individuals that utilize those resources. Achieving a successful networking environment requires not only effective distribution of information resources but also a suitable distribution of support responsibilities. The end users of network services must participate in the administration of campus networking facilities if timely reporting and resolution of problems, managed growth, coordinated change, and productive utilization are to be achieved.

The hierarchical structure of modern networks provides a natural means for demarcating the distribution of these support responsibilities. To illustrate, most campus networks today, including the University of Georgia campus network, consist of distinct departmental or workgroup local area networks (LANs) which are connected to a campus backbone network. The campus backbone network in turn connects to other campus information resources as well as wide area networks such as the Internet. In other words, current campus networks can be accurately referred to as "networks of networks".

Differentiating and assigning support responsibilities for each level of network in this hierarchy is natural and appropriate. In particular, those groups using a common LAN or sharing common network requirements must participate in the design, implementation and operation of their private networking facilities if a responsive networking environment is to be achieved for the workgroups involved. Similarly, various support responsibilities must be provided centrally if institutional requirements for reliability, interoperability and affordability of networking services are to be achieved. Another major responsibility of a central support organization must be assisting individual units in migrating to productive local networking environments. This is the distributed support model which has been followed successfully at the national level for the Internet.

The following sections describe the distribution of network support responsibilities which have evolved at the University of Georgia. Both central and local roles are described. The extent of local support responsibilities depends on the complexity and magnitude of the network domain. At a minimum each network domain (which is defined subsequently) is expected to designate a Domain Network Liaison to coordinate central support services. The responsibilities of this position are intentionally prescribed so as not to require the employment of additional staff. An appendix to this document lists the classified position descriptions which have been established for employment of technical support personnel in those complex local networking environments where this support is appropriate.

1.1 Central Network Support Responsibilities

At the University of Georgia, central support of campus networking activities is the responsibility of Enterprise Information Technology Services (EITS). Two support functions have been identified to meet this responsibility. These functions are known generically as the Network Operations Center (NOC) and the Network Information Center (NIC). The complexity and extent of modern computer networking requires that both the NIC and NOC functions draw on the expertise of several technical support groups within EITS to meet their campus network support responsibilities. They may also call on individuals and organizations outside of EITS or even external to the University in satisfying their missions. The EITS unit primarily responsible for administering NIC and NOC services is the Division of Operations and Network Infrastructure.

1.1.1 NOC Responsibilities

The role of the NOC is operational management and support for all EITS provided equipment and networking facilities. These include the trunk broadband and fiber optic cable plants and associated components, building bridges/routers, centrally located data communications equipment, centrally installed building spine cable facilities and connection facilities to wide area network services such as Internet and other communication carriers.

Operational management and support in the context of NOC responsibilities refers to the reliable and proper functioning of the physical facilities used to provide network connectivity. These responsibilities include continuing maintenance for the facilities involved, monitoring network performance, managing change for the campus trunk networking system, and maintaining master lists for all connected devices and contact individuals.

NOC responsibilities also include coordinating, scheduling, and certifying additions or changes to centrally supported building spine facilities. This responsibility includes design and installation management of LAN facilities to be attached to building spines. In this role the NOC utilizes the campus Electronic Design and Maintenance Shop and state contract vendor Key Services as material and labor suppliers.

Another NOC function of direct significance to users of campus networking services is network problem determination and resolution. Problems in this context refer to the inability of clients to successfully connect to the campus network from their local workstations and access distributed information resources. Although a number of diagnostic tools are available to the NOC for this purpose, it is expected that clients will report network problems directly to the NOC, either through the telephone or an electronic message.

Problem resolution procedures followed by the NOC include logging and tracking the incident, isolating the cause of the problem, taking corrective action when the problem is due to a NOC supported facility, or transferring responsibility for problem resolution to other appropriate support persons or groups when the problem is outside of the domain of NOC supported facilities or expertise. In all cases, responsibility for tracking the problem and reporting ultimate resolution status to the client remains with the NOC. NOC responsibilities do not include the content of the information services provided through networking facilities, the effective and knowledgeable use of network services by connected clients, or maintenance of local area network facilities. Hardware repair for most LAN equipment, particularly servers and client workstations, interface board installations and cable plant moves and changes is available, however, through the Electronic Design and Maintenance Shop.

1.1.2 NIC Responsibilities

The role of the Network Information Center (NIC) can generally be described as technical support, training, and information services in adapting networking technologies to the client work environment. These efforts focus primarily on effective use local area network facilities involving personal computers or multiuser workstations. Examples of the support services available from the NIC include consultation to determine the benefits of networking in a particular work environment, information on different networking options available, configuration specifications and cost projections for selected local networking environments. The NIC will also interface with the NOC in developing detailed cable design and installation specifications for the LAN configuration selected.

When a LAN system has been selected, the NIC can also provide support in configuring and installing selected network server and terminal emulation software. The network server software environments supported include NetWare, Windows NT/2000, and UNIX operatins systems. The terminal emulation software supported by the NIC provides connectivity across the network using TCP/IP protocols. Both proprietary and public domain terminal emulation software are supported. The public domain terminal emulators supported by the NIC are also distributed through the EITS Help Desk.

The NIC offers a variety of training seminars for network users as well as providing numerous network reference materials. The training courses are provided quarterly in cooperation with the University Training and Development department. These courses range from an introduction to networking concepts to administration of Novell Netware systems. Reference information is provided in both printed form through the EITS Help Desk and through public access network bulletin boards. Another information service provided by the NIC is sponsorship of network user groups. To date, two user groups have been established on the campus to facilitate exchange of experiences and information relating to computer networking. One is the UGANET Network Managers user group and the other is the Novell System Administrators user group.

NIC staff are also available to local network support staff in resolving technical problems in the operation of LAN facilities. This support is restricted to the LAN operating environments with which NIC staff are familiar. Typically these problems are referred to the NIC after they have been reported to the NOC by clients. Resolutions for these problems are normally provided as recommended corrective actions which the local network administrator can take.

Evaluation of new local area network products is another responsibility of the NIC. Typically the products evaluated are new releases of network server operating systems, file and print server utilities and LAN management tools. Hardware products are also evaluated including gateway devices, LAN interface boards and server systems. This activity is essential in the rapidly changing world of computer networking in order that the consultation and training support provided to clients be current.

1.2 Network Domain Support Responsibilities

A descriptive term which has been evolved to define the distributed level of network organization in our campus hierarchical network environment is a network domain. A network domain is a subset of the campus network that may span a portion of a building, an entire building, or a number of buildings. The domain can represent a department, a set of departments, a college, or a group of individuals utilizing shared network addressable computing resources. Typically, a network domain will consist of those users within a single department connected to a common LAN in a specific building. However, because network connectivity eliminates location dependencies for interaction, more general network domains must be envisaged.

For each network domain, it is essential that a domain network liaison (DNL) be identified. This individual serves as the primary point of contact for that domain, both with respect to the other users within the domain and the central EITS network support groups. The responsibilities of the DNL have been delimited so as not to require a full-time equivalent position. It is expected that the responsibilities can be performed by existing staff in a manner similar to the coordinators identified in the past for voice telephone services. Orientation and training for DNLs is provided by the EITS Network Information Center. This latter group and the EITS Network Operations Center are also available to assist the DNL in dealing with problems which may not have been anticipated in the training provided or which go beyond the competency of the DNL to resolve.

The following items summarize the primary responsibilities of the domain network liaisons:

  1. The DNLs are responsible for maintaining critical information for every network node (microcomputer, workstation, etc.) under their purview. Examples of such information include network names and addresses, building and room locations, node ownership, and contact information.

  2. In cooperation with the EITS Network Information Center, the DNLs will assign network addresses, such as TCP/IP addresses, to new nodes in their network domain and will be a focal point for requests to EITS for critical network parameters, node name registration, and other pertinent networking information.

  3. The DNLs will serve as the primary point of contact for problem reporting caused by network nodes, cabling, or communications devices in their domain or for problems experienced by their network users. The DNLs will either solve the problems directly if their expertise permits or forward them to technical support staff within their domain (if they exist) or to the EITS Network Operations Center for resolution.

  4. The DNLs must have access to the locations where nodes are attached to the network and must have the authority to disconnect malfunctioning nodes from the network until they can be fixed, if requested by EITS network support personnel.

  5. The DNLs will be responsible for notifying their users of pertinent campus network information provided by EITS including planned network downtime at the building and/or campus level.

  6. In the case where multiple domains exist within a building, the DNLs will coordinate with other DNLs and appropriate UGA personnel when they wish to attach any network devices to common spine facilities within the building.

  7. Every DNL must have an Internet-accessible electronic mail address to which important messages such as network downtime can be sent.

  8. DNLs, or designated substitutes, must be available on a continuing basis during normal working hours for effective administration of network domain activities.

If you need to look up DNLs by name, by building, or by organization, you can search DNL contact information here.

It is important to note the responsibilities of the DNL do not explicitly include physical installation of networking facilities or their technical support. In large and complex domains, technical support staff will be necessary. In these environments the responsibilities of the DNL may be assumed by these staff.

Characteristics of networking domains where technical support staff are necessary are those which include networking components such as file servers, print servers, mail gateways, etc. This support may be provided at the departmental, school, or college level. Whether this support represents a full-time level of commitment or less is a function of the extent and criticality of the domain network services. The EITS NIC can assist in assessing the level of support required for a particular domain.

2. Network Information Management

One of the primary responsibilities of DNLs is the management of critical information for networked computing resources (e.g., microcomputers, multi-user workstations, communications devices, etc.) within their domain. The primary purpose of maintaining network information is to assist local or EITS technical network support personnel in the identification and isolation of misconfigured or malfunctioning networked resources. This information includes the locations of the resources (buildings and room numbers), the individuals operating or responsible for those resources (names and phone numbers), and any network names and numbers associated with those connected devices (e.g., network interface card (nic) addresses, IP addresses and domain names, IPX network numbers and Novell server names, and AppleTalk network numbers and zone names. DNLs can choose any management tool in which they wish to store the information. Examples of information management tools include text and word processors, spreadsheets, or flat file or relational databases. (Note: Since there is currently no central database in which to store network information, DNLs are not expected to send updated domain information to the University of Georgia's Network Information Center (UGA NIC).)

DNLs are also responsible for requesting or registering network names and addresses through the UGA NIC. Only officially registered domain network liaisons can request or register network names and addresses through the UGA NIC.

2.1 Network Interface Card Information

One critical piece of network information that needs to be recorded is the hardware address of the network interface card (nic). A nic is either an Ethernet or Token Ring card. The nic address can be important when troubleshooting networking problems because, at times, it is the only piece of information available to network support personnel. Having a list of nic addresses for networked computers can expedite problem resolution times by pinpointing the source of the problem quickly.

In addition, having a list of nic addresses is useful when setting up a centralized method of supplying IP networking parameters to computers either through DHCP (Dynamic Host Configuration Protocol - *preferred*) or BOOTP (BOOTstrap Protocol). When a computer is configured to obtain IP networking parameters via DHCP/BOOTP, it sends a broadcast message (which is heard by all DHCP/BOOTP servers on the same physical network) requesting its IP parameters. The DHCP/BOOTP server that has the computer's nic address in its database responds with the appropriate information.

The nic address is a 12-hexadecimal-digit number that is unique to that network card. (A hexadecimal digit consists of the numerical digits '0' through '9' and the alphabetic digits 'A' through 'F'.) Nic addresses are typically represented as a string of 12 uppercase characters (e.g., '0000C0F4D5C0'), sometimes with dashes (e.g., 00-00-C0-F4-D5-C0), or in "colon notation" with every two digits (lowercase alphabetic characters) separated by a colon character with leading zeroes removed (e.g. 0:0:c0:f4:d5:c0, identical to the representations above).

One method for determining the hardware address of a network card is to look for an address label on the card prior to installing the card in the computer. If the card has already been installed, it is possible to determine the nic address via software.

On a Windows workstation running the Trumpet Winsock TCP/IP software, the nic address is displayed in the Trumpet console window when the software is loaded. (If this window has be "iconized", double click on the icon with the trumpet and the letters TCP on it to view the window.) On a Windows 95/98 workstation, the nic address can be viewed by selecting Start-->Run and entering winipcfg. (On Windows NT workstations, select Start-->Run and enter ipconfig.)

For Macintosh users, one can obtain the nic address by selecting the Control Panel option under the "Apple" icon, selecting the MacTCP option, holding down the <Option> key, and clicking on the Ethernet icon. (The nic address will appear under that icon.) However, some of the newer Macs *must* be connected to the network for this method to work. Alternatively, there are several small utilities (GetMyAddress, Apple Lan Utility, Node Informer) that display the nic address and will concatenate it to a master file for reference. These utilities will work even if no network connection is in place. Please contact EITS LAN Support through the EITS Help Desk ( or 542-3106) if you would like to obtain any of these programs. Macs connected through a Gatorbox LocalTalk-to-Ethernet gateway will all have the same nic address -- that of the Gatorbox. Gatorbox nic addresses are displayed via the Gatorkeeper program using the Special, Info options.

2.2 IP Information

The Transmission Control Protocol over Internet Protocol (TCP/IP) suite is the standard set of communications protocols used at the University of Georgia (UGA). In fact, the TCP/IP protocol suite is the standard used for the global Internet and is the only communications protocol that is set up to access non-UGA computing resources. IP addresses and domain names are the primary networking parameters associated with computers that communicate via TCP/IP.

2.2.1 IP Addresses and Domain Names

Each computing resource that communicates via TCP/IP must have a unique set of numbers (called the IP address) assigned to it. An IP address consists of four numbers in the range 1 through 254, separated by three dots (or period characters). The University of Georgia has been assigned a range of IP addresses of the form, where xxx is referred to as the building subnet number (1-254) and yyy is the unique number (2-249) assigned to each TCP/IP computing resource in that building. (Note: There are four other IP parameters that are needed to properly configure a TCP/IP resource. They are the netmask (, the default gateway (, the primary domain name server ( and the secondary domain name server (

Each building is minimally assigned one subnet number xxx, and all computing resources in a given building must be assigned IP addresses in the range In most buildings, there is only domain (usually a department), and that domain is assigned the entire subnet range. In some buldings, however, there is more than one domain, and the subnet ranges must be appropriately divided among the various domains in those buildings. If a range of IP addresses is needed for a domain within a building, the DNL *must* fill out the form at the link "Request more IP numbers" on the MyDNL page and request an IP address range for that building. (NOTE: The DNL Web Registration System requires your UGA MyID and password to access it. DNLs are **strongly encouraged** to read the system overview before using the DNL Web Registration System the first time.) IMPORTANT NOTE: It is imperative that DNLs obtain IP address ranges from the NIC because there are a number of central networking databases that need to be updated when these ranges are assigned.

DNLs are responsible for assigning unique IP addresses to the computing resources within their domain. They are encouraged to assign IP addresses sequentially starting with the smallest number in their assigned range. This practice is encouraged because another domain may need some of the available IP addresses at a later time, and it is easier and more desirable to reassign IP addresses in a contiguous set from the high end of the unused range. Once an IP address has been assigned to a computing resource, that address should be added to the DNL's network information database along with the other information listed above.

A TCP/IP computing resource can also be optionally assigned a name called a fully qualified domain name (FQDN) that is typically associated with a specific IP address. The associations between IP addresses and FQDNs are stored in distributed databases on computing resources called domain name servers. All TCP/IP applications rely on these distributed name servers to provide IP addresses when they only have FQDNs with which to specify a TCP/IP resource.

Although FQDNs are not required for TCP/IP communications to function, DNLs are *strongly* encouraged to register FQDNs in the campus name servers when they assign IP addresses to TCP/IP computing resources. Some TCP/IP server resources require TCP/IP client resources to be registered in a name server before they will permit access to information stored on them. The University of Georgia's anonymous FTP server is an example of a TCP/IP computing resource that requires name server registration before it will allow access to its information. DNLs should also record the assigned FDQNs in their network information databases.

FQDNs at the University of Georgia have the form where edu refers to all educational organizations in the U.S., uga refers to the University of Georgia, subdomain is a name that reflects an officially recognized organization on campus (only one subdomain name is allowed per organization), and resource is a unique name for the TCP/IP resource. For example, the FQDN corresponds to the computing resource named dmm within the ucns organization at the University of Georgia. (Note: Resources in different buildings can be assigned the same subdomain names, but subnet numbers must be assigned to individual buildings.)

It is important to note that DNLs can *only* register names of the form where is the registered subdomain name for which they are responsible. Requests for names of the form or where non-subdomain is not an official subdomain name will *not* be honored, with the possible exception of a name that represents a campus-wide computing or information resource that serves the entire UGA community.

FQDNs are case insensitive, and resource and subdomain names must begin with an alphabetic character followed by one or more alphanumeric characters (seven or less is recommended for mininal typing effort). The dash character '-' is the *only* non-alphanumeric character allowed in FQDNs. For computing resources utilized by individuals, resource names are typically the individuals' initials or first initials and last names (up to eight characters total). Resource names that reflect the type of computer hardware (e.g., or or the type of software operating system (e.g., or are discouraged because they give computer hackers clues to any security holes that may exist in a computer's operating system or networking software.

Most FQDNs are uniquely associated with IP addresses. These are referred to as address (or "A") records. To register new FQDNs with assigned IP addresses (or to delete or change existing entries), DNLs must use the online MyDNL page and select the "Domain Name System (DNS) requests" option. (NOTE: The DNL Web Registration System requires your UGA MyID and password to access it. DNLs are **strongly encouraged** to read the system overview before using the DNL Web Registration System the first time.) Once the NIC has received the request, the name server changes will be performed within three working days.

TCP/IP computing resources can also have aliases for their primary FQDN. These aliases are called "CNAME" records. Aliases at the University of Georgia must be of the form where alias is a name that typically reflects a specific type of TCP/IP resource. World Wide Web servers ( and FTP servers ( are examples of typical TCP/IP computing resources that have FQDN aliases. (Note: A TCP/IP computing resource can have more than one alias, if it provides more than one TCP/IP service.) To register an alias name with an existing FDQN (or to delete or change existing entries), DNLs must use the online MyDNL page and select the "Domain Name System (DNS) requests" option, then fill out the "'MX' and 'CNAME' Records" section of the form.

TCP/IP computing resources that send and receive electronic mail must have mail aliases in the name server. These aliases are called "MX" records. Mail aliases at the University of Georgia are typically of the form but they can also be of the form where alias is usually the same as in the FQDN. To register a mail alias with an existing FDQN (or to delete or change existing entries), DNLs must use the online MyDNL page and select the "Domain Name System (DNS) requests" option, then fill out the "'MX' and 'CNAME' Records" section of the form.

2.2.2 LPD Server Registration

TCP/IP printing is usually accomplished by a client printing program (LPR) sending output to a server printing program (LPD) via TCP/IP communications. Individuals who wish to send printed output from the UGA IBM MVS computing resource (on which the TSO time sharing system and the IMS financial and student information systems run) to distributed computing resources via LPR/LPD, must have their DNLs register their LPD server through the UGA NIC. LPD servers can run on microcomputer operating systems such as Windows, Windows NT, Windows 95, OS/2, Novell, MacOS and on multi-user workstations running Unix.

To register LPD servers, DNLs must use the online MyDNL page and select the "Mainframe LPD Registration" option. This registration requires the knowledge of the following information:

Since most individuals who want printers registered want to print from IMS financial and student information systems, the DNL will also need the following information:

2.3 IPX Information

IPX (Internetwork Packet eXchange) is the communications protocol developed by Novell to deliver packets of data in a connectionless fashion, i.e., delivery without regard to packet order. Novell later developed the Sequenced Packet eXchange (SPX) protocol to provide a connection-oriented packet delivery mechanism. For both specifications, there is a common network numbering scheme and the numbers will be referred to as IPX numbers.

A physical IPX network consists of all devices connected by cabling and communications devices such as hubs, repeaters, and/or bridges. Multiple physical networks are separated by IPX routers. (Note: At one time, Novell used the term "bridge" to refer to a computer that routed IPX packets between two physical networks. The bridges mentioned above refer to Ethernet, Token Ring, or the campus backbone bridges.)

Every physical network has one unique hexadecimal number (called the IPX network number) associated with it. In addition, every Novell server that is running version 3.x or higher has a "virtual" physical network in software that requires a unique internal IPX number.

All information regarding IPX network numbers is provided and maintained by IPX routers. An IPX router is typically a Novell server but it could be a commercial router such as a Cisco or Wellfleet, a Shiva NetModem or Telebit Netblazer supporting IPX remote node services, or other communications devices that route IPX. The router's software maintains a separate IPX network number for each physical interface to which it connects. For NetWare 3.x (or higher) servers, an internal IPX number is also needed. In order for IPX to function properly, all routers that are connected to the same physical network must have the same IPX network number associated with that interface.

Because IPX network numbers must be unique, DNLs must request new IPX network numbers through the "Miscellaneous NIC Request" option on the MyDNL page when a new IPX router is installed on the campus network. (NOTE: The DNL Web Registration System requires your UGA MyID and password to access it. DNLs are **strongly encouraged** to read the system overview before using the DNL Web Registration System the first time.) It is assumed that the IPX router will be connecting to one or more physical networks that have not been assigned IPX network numbers. In the case of new Novell servers, the internal IPX number corresponding to the "virtual" network is the minimal network number that must be assigned. (Important Note:Since Novell server names must also be unique, these names must also be registered with the UGA NIC.)

2.4 AppleTalk Information

AppleTalk is the set of communications protocols developed by Apple Computer to give Macintoshes the ability to exchange digital information over networks such as Ethernet, Token Ring, or Apple's LocalTalk. Low-level software drivers (EtherTalk, TokenTalk, or LocalTalk, respectively) communicate directly with the appropriate network interface card, and AppleTalk software provides the routing- and higher-level networking services such as file and printer sharing. These services are respectively specified by the Routing Table Maintenance Protocol (RTMP) and Zone Information Protocol (ZIP), the Apple Filing Protocol (AFP) and the Printer Access Protocol (PAP).

For the purpose of this discussion, a physical (AppleTalk) network consists of all devices connected by cabling and communications devices such as hubs, repeaters, and/or bridges. Multiple physical networks are separated by AppleTalk routers.

Every physical network has one or more contiguous AppleTalk network numbers associated with it. A LocalTalk network can have only one AppleTalk network number, but Ethernet and Token Ring networks can have one or more contiguous AppleTalk network numbers (referred to as the network cable range).

Because AppleTalk network numbers must be unique, DNLs must request a new network number or cable range through the "Miscellaneous NIC Request" option on the MyDNL page when a new AppleTalk router is installed on the campus network. (NOTE: The DNL Web Registration System requires your UGA MyID and password to access it. DNLs are **strongly encouraged** to read the system overview before using the DNL Web Registration System the first time.) An AppleTalk router could be a Cayman Systems Gatorbox, a Novell server running NetWare for Macintosh software, a Shiva NetModem supporting AppleTalk Remote Access (ARA) services, or other communications devices that route AppleTalk. In the case of Novell servers, there is a "virtual" LocalTalk network provided by the server software that requires a separate network number.

AppleTalk also implements a naming scheme which centers around the concept of a zone. An AppleTalk zone refers to a named, logical grouping of AppleTalk devices that have a common organizational affiliation or function. Under the current AppleTalk specification, there can be a maximum of 256 AppleTalk zones for the entire enterprise network.

The networked devices associated with an AppleTalk zone can span one or more physical networks, i.e., the same zone name can span multiple physical networks. A LocalTalk network can only have one zone name associated with it, but Ethernet and Token Ring networks can have a set of zone names (called a zone list) associated with them. Zone names at the University of Georgia have the form UGA-domain_name where domain_name is a 1-43 character name for the organization representing a given domain. Upper and lowercase alphabetic and blank characters are permitted in the zone name.

Since there are only 256 total zone names allowed on an enterprise AppleTalk network, only one zone name will be assigned by the NIC to each domain. DNLs who have not requested an AppleTalk zone name can register one (of the form UGA-domain_name) with the UGA NIC through the "Miscellaneous NIC Request" option on the MyDNL page Because of the manner in which information is updated on an AppleTalk network, new zone names will only be activated on an annual basis (typically January of each year). DNLs will be informed of the specific dates when activation will occur.

3. Network Problem Resolution

If problems occur within a network domain and the DNL has the technical training to look into the problem, he or she is expected to be the initial point of contact for individuals utilizing the networked resources within that domain. If the nature of the problem appears to be beyond of the expertise of the DNL, either the DNL or the individual experiencing the problem should contact the EITS Helpdesk ( or 542-3106) for assistance during the hours of 8:00 a.m. to 5:00 p.m. Monday through Friday.

A DNL will serve as a point of contact for technical network support personnel from EITS or other network domains, if those personnel have identified a computing resource within the DNL's domain as causing network problems for others. The DNL must be prepared to provide location and contact information for that computing resource to technical support staff and must have the authority to disconnect the resource from the network, if necessary.

4. Network Notification

Periodically it is necessary for central EITS computing and networking personnel to announce planned and unplanned changes (when possible) to either centrally supported computing resources on the UGA network or to the campus backbone itself. DNLs must have an Internet accessible e-mail address to which notification messages can be sent. The LISTSERV discussion list UGANL ( has been set up to distribute notification messages to all DNLs. (NOTE: DNLs who also provide technical network support can subscribe to the UGA Network Managers UGANET list ( instead of the UGANL list.) DNLs are encouraged to set up electronic distribution lists containing the e-mail addresses of all individuals within their domain of responsibilities to whom they wish to forward these messages.

5. DNL Changes

DNLs are expected to be generally available during working hours throughout the year to serve as points of contact for network problems within their domains. It is realized that a DNL may have to be off campus for extended periods of time (vacations, business travel, etc.) During those time periods, the DNL is expected to designate a temporary DNL to serve as the point of contact. The permanent DNL must send a message through the "Change/Add/Remove who is a DNL for your unit(s)" option on the MyDNL page indicating who will serve as temporary contact, what their phone number and e-mail address are, and what periods of time the temporary DNL will fill that role.

From time to time, individuals serving as DNLs for network domains may no longer carry out those responsibilities, e.g., due to a change in job duties or due to job termination. In that event, DNLs or the administrative heads for the organizations represented by those domains must send a letter to the campus network liaison or existing DNLs can send a message through the "Change/Add/Remove who is a DNL for your unit(s)" option on the MyDNL page indicating who the replacement DNL will be, when that individual has been identified.