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.
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.
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.
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.
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:
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.
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 (email@example.com 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.
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.
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 128.192.xxx.yyy, 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 (255.255.0.0), the default gateway (22.214.171.124), the primary domain name server (126.96.36.199) and the secondary domain name server (188.8.131.52).
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 128.192.xxx.2-249. 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 https://db.uga.edu/network/dnl/ 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 resource.subdomain.uga.edu 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 dmm.ucns.uga.edu 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 resource.subdomain.uga.edu where subdomain.uga.edu is the registered subdomain name for which they are responsible. Requests for names of the form resource.uga.edu or resource.non-subdomain.uga.edu 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., sun.subdomain.uga.edu or quadra.subdomain.uga.edu) or the type of software operating system (e.g., win95.subdomain.uga.edu or system7.subdomain.uga.edu) 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 https://db.uga.edu/network/dnl/ 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 alias.subdomain.uga.edu where alias is a name that typically reflects a specific type of TCP/IP resource. World Wide Web servers (www.subdomain.uga.edu) and FTP servers (ftp.subdomain.uga.edu) 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 https://db.uga.edu/network/dnl/ 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 subdomain.uga.edu but they can also be of the form alias.subdomain.uga.edu 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 https://db.uga.edu/network/dnl/ and select the "Domain Name System (DNS) requests" option, then fill out the "'MX' and 'CNAME' Records" section of the form.
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 https://db.uga.edu/network/dnl/ 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:
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 https://db.uga.edu/network/dnl/ 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.)
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 https://db.uga.edu/network/dnl/ 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 https://db.uga.edu/network/dnl/. 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.
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 (firstname.lastname@example.org 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.
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 (email@example.com) 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 (firstname.lastname@example.org). 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.
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 https://db.uga.edu/network/dnl/ 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 https://db.uga.edu/network/dnl/ indicating who the replacement DNL will be, when that individual has been identified.