Home > Articles

Novell eDirectory

This chapter is from the book

This chapter is from the book

Using eDirectory Objects

Test Objectives Covered:

  1. Identify and describe eDirectory object classes.

  2. Identify the flow and design of the eDirectory tree.

The Directory consists of the schema, objects, properties, and values.

The schema defines the types of objects that you can create, as well as what information is required when the object is created. Each type of object has associated with it a defined schema class. NetWare 6 ships with the base schema, which when modified becomes known as an extended schema. Modifications to the schema usually are done with the Schema Manager in the ConsoleOne utility.

An object is similar to a record or row of information in a database table. It contains information about a particular network entity. eDirectory represents each network resource as an object in the Directory. For example, a User object represents a particular user on the network. An object can be a physical resource (such as a workstation), an eDirectory resource (such as a group), or an organizational resource (such as a container).

An object property is similar to a field in a database record. It is a category of information you can store about an object. For example, properties of a User object include such things as Login Name, Password, and Telephone Number. Each type of object has a specific set of properties associated with it; this defines its class. Properties are predefined by eDirectory and determine how a given object can be used. For example, Server properties differ from Printer properties because they are different eDirectory objects with different functions.

Three important types of eDirectory properties are the following:

  • Required properties—These properties contain vital object data and, therefore, must be supplied to create the object. Required properties can't be deleted. For example, when you create a User object, you must indicate values for the Login Name and Last Name properties. In fact, the name of an object is always a required property. Otherwise, you would have no way of referring to it.

  • Optional properties—These properties contain nonvital information about an object. As such, you need to supply values for them only if desired. Examples include a User's Title, Telephone Number, and Fax Number.

  • Multivalued properties—These properties support more than one entry. For example, the Telephone Number property associated with a User object can hold multiple phone numbers for that user. Other User-related multivalued properties include Title, Location, and Fax Number. (This type of multivalued property is represented in ConsoleOne with an ellipsis (...) button to the right of the property field. If you click this button, you'll be allowed to enter additional entries for the property.)

Finally, a property value is similar to a data string in a field of a database record. In other words, it's a data item associated with a property. For example, the value associated with the Password property of a User object would be the actual password for that User object.

Refer to Table 3.2 for an illustration of the relationship between eDirectory objects, properties, and values.

Table 3.2 Understanding eDirectory Objects, Properties, and Values





Login Name

AEinstein (also known as AEinstein.LABS.NORAD.ACME)


Super Smart Scientist





Printer (Non NDPS)



Default Print Queue


Print Server


NetWare Server

Other Name



Novell NetWare 6.01g°





Hierarchy of eDirectory

As you learned earlier, the Directory is an object-oriented database that is organized in a hierarchical structure called the eDirectory tree. It provides a way to view the logical organization of network resources stored in the Directory database. As you can see in Figure 3.5, the tree is similar to the DOS file system.

Figure 3.5Figure 3.5 Understanding eDirectory objects.

The schema contains object classes, which represent the actual definition of each type of eDirectory object. eDirectory contains the following three main classes of objects:

  • Tree Root

  • Container objects

  • Leaf objects

The top of the tree is called the Tree Root. Container objects, which are analogous to folders, define the organizational boundaries of the Directory and are used to store other container objects and/or leaf objects, depending on which type of container they are. (A container object is called a parent object if it contains other objects.) Leaf objects, which are analogous to files, are typically stored in container objects. They are the physical or logical network resources that provide technical services and WAN functionality. Leaf objects define the lowest level of the eDirectory structure and therefore cannot contain other objects.

The main difference between eDirectory and DOS architecture is that eDirectory containers have restrictions on where they can be placed and what can be placed in them. Typically, each NetWare 6 network will have only one eDirectory tree. If a network has more than one tree, each will function as a separate, independent database. In other words, resources cannot be shared between them.

In the Directory, each network resource is defined as a logical object. There are a number of types of objects. For example, an object can represent a person (such as a user), a physical resource (such as a printer), an eDirectory resource (such as a group), or an organizational resource (such as an Organizational Unit container).

The bottom line is this—users don't access physical resources anymore. Instead, they access logical objects in the eDirectory tree. This means they don't need to know which NetWare 6 server provides a particular resource. All they need to know is where the resource exists in the logical eDirectory world.

Now that you've mastered the subtle differences between eDirectory schema, objects, properties, and values, let's explore some of the most interesting objects in detail, starting at the top with the Tree Root.


One of the best ways to remember the nuances of eDirectory hierarchy is to follow the yellow brick road to the land of 3s:

  • Main eDirectory Components in the Schema: Object, Property, Value

  • Main Classes of Objects: Tree, Container, Leaf

  • Main Container Objects: Country (C), Organization (O), Organizational Unit (OU)

Tree Root

The Tree object (also known as the Tree Root) is a required object that defines the top of the eDirectory organizational structure. Because it represents the opening porthole to the eDirectory world, its icon is appropriately a picture of a tree. Each Directory tree can have only one Tree Root, which is created during installation of the first server in that tree. The only objects that can be created directly under the Tree are Country, Organization, and Alias. (In this case, the Alias object can point only to a Country or Organization.)

Although some people think of the Tree as a container object (because it contains all the objects in the Directory), it differs from other container objects in the following ways:

  • It cannot be created except during installation of the first NetWare 6 server on a network.

  • It is essentially a placeholder; it has only one property: Name. The Tree name is shown in the hierarchy of ConsoleOne.

  • It cannot be moved, deleted, or renamed.

  • It uses the eDirectory tree name, which can be changed at a later date.

Like other objects, the Tree can be assigned as a trustee of other objects, and other objects can be granted trustee access rights to it. For example, an object can be granted trustee rights to the entire eDirectory tree by making the object a trustee of the Tree object. (See Chapter 6, "NetWare 6 Security," for further information on trustee rights.)

Container Objects

Container objects are logical objects that organize (store) other container or leaf objects. A container can represent a country, a location within a country, a company, a department, a responsibility center, a workgroup, or a collection of shared resources. Each class of container object has different rules that define what it can contain and where it can be located in the tree. Each class also has different properties.

The following are the three most common types of NetWare 6 container objects:

  • Country—Designates the country where certain parts of the organization reside.

  • Organization—Represents a company, university, or department. eDirectory supports only one layer of Organization objects; hence, the term one-dimensional. Organizations can hold Organizational Unit containers or Leaf objects.

  • Organizational Unit—Represents a division, a business unit, or a project team within the Organization. Organizational Units hold other Organizational Units or leaf objects. They are multidimensional.

Refer to Figure 3.5 earlier in this chapter for an illustration of the relationship between the Tree Root and container objects. The ACME Organization houses other Organizational Units (including LABS), that in turn house leaf objects (like AEinstein). In the next sections, you'll take a closer look at these three container objects.


The Country object is an optional container that organizes a Directory tree by country. This type of object can be defined only directly under the Tree Root and must be named using a two-character abbreviation. Novell states that you must use a valid two-character country abbreviation. Presumably, this is to ensure that your network is in compliance with the two-character abbreviations defined in the ISO X.500 standard.

Interestingly, if you create a Country object using the ConsoleOne utility, it allows you to use any two-character name. To determine which two-character names are compliant with the ISO X.500 standard, click Help when creating the Country object, and NetWare 6 will tell you. You can also visit the ISO Web site at http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html to see a list of country codes. The only objects that can exist in a Country container are an Organization or Alias object pointing to an Organization.


If you don't have any compelling reasons to use the Country object, stay away from it. It adds an unnecessary level of complexity to your network. In fact, Novell doesn't even use the Country object in its own multidimensional, worldwide eDirectory tree.


If you don't use a Country object, the next layer in the tree is typically an Organization. You can use an Organization object to designate a company, a division of a company, a university or college with various departments, and so on. Every Directory tree must contain at least one Organization object. Therefore, at least one Organization is required. Many small implementations use only the Organization object and place all their resources directly underneath it. Organization objects must be placed directly below the Tree Root, unless a Country object is used. Finally, Organization objects can contain all objects except Tree Root, Country, and Organization.

Earlier, we defined the Organization as a one-dimensional object. This means the tree can support only one layer of Organization objects. If you look closer at the icon, you'll see a box with multiple horizontal boxes underneath. Additional vertical hierarchy is defined by Organizational Units, which are multidimensional. You'll learn about them in just a moment.

Figure 3.6 illustrates the object dialog box for the ACME Organization using ConsoleOne. On the right side of the screen are the many page buttons that identify categories of eDirectory properties for this object. Associated with each page button is an input screen for a specific set of information (on the left side). The Identification page button (shown here) allows you to define a variety of Organization properties, including Name, Other Name, Description, Location, Telephone, and Fax Number.

Similar page buttons enable you to configure important Organization parameters, including postal information, print job configurations, trustee assignments, and so on. As far as ACME is concerned, the Organization container defines the top of the functional tree.

Figure 3.6Figure 3.6 Properties of an eDirectory Organization object.

Organizational Unit

The Organizational Unit object is a natural group. It enables you to organize users with the leaf objects they use. You can create group login scripts, a user template for security, trustee assignments, security equivalences, and distributed administrators. Although the Organizational Unit container is optional, you should definitely use as many as you need to build a scalable hierarchy for two main goals: resource access and partitioning.

Organizational Units can represent a division, a business unit, a project team, or a department. Organizational Units are multidimensional, in that you can have many hierarchical levels of containers within containers. Remember, Organization objects can exist only at one level in the eDirectory tree.

Organizational Units are the most flexible containers because they can contain other Organizational Unit objects or leaf objects. Organizational Units can contain most of the eDirectory object types, except the Tree Root, Country, or Organization containers (or Aliases of any of these).

Now take a look at the real stars of the eDirectory world—leaf objects.


eDirectory supports many other special-use container objects. Five that you may frequently run across are Locality (L), Domain (DC), License Container (LC), Security Container (S), and Role-Based Service (RBS).

The "secret" Locality object is similar to the Country object, in that it's optional and not created as part of the default NetWare 6 installation. If desired, you can use a Locality object to designate the region where your organization's headquarters resides. Unlike Country objects, Locality objects can reside either under the Country, Organization, or Organizational Unit containers.

In addition, NetWare 6 supports three types of administration container objects: a License Container, a Security Container, and a Role-Based Service container. These objects are added to the eDirectory tree when NetWare 6 and Novell Licensing Services (NLS) are installed. They appear as eDirectory objects in the container that includes the Server object. License Container objects can contain multiple-license Certificate leaf objects. Security Containers hold global login and authentication policies, whereas RBS containers hold Role leaf objects for distributing key administration tasks to groups of users.

Finally, Domain containers enable you to use your Domain Name System (DNS) to help locate services in the eDirectory tree. Domain objects can reside directly under the Tree Root, or within Country, Organization, Organizational Unit, or Locality containers.

Leaf Objects

Leaf objects represent logical or physical network resources. Because leaf objects reside at the end of the structural eDirectory tree, they cannot be used to store other objects. In other words, they represent the proverbial "end of the road." As you learned earlier, each class of leaf object has certain properties associated with it. This collection of properties differentiates the various leaf object classes from each other. For example, User objects contain different properties than Printer objects do.

The following are some of the key leaf objects covered in this course:

  • Alias—An Alias object points to another object that exists in a different location in the eDirectory tree. It enables a user to access an object outside of the user's normal working context (that is, container). An Alias object does not carry trustee rights.

  • Application—An Application object enables network administrators to manage applications as objects in the eDirectory tree. The advantage of this object is that users don't have to worry about drive mappings, paths, or rights when they want to execute an application. This information is defined by Application object properties.

  • Directory Map—A Directory Map object represents a logical pointer to a physical directory or folder in the NetWare 6 file system. This object is useful in mapping statements because it enables you to map a drive to a resource without knowing its physical location. If the path to the resource changes, you need to change only the path designated in the Directory Map object, rather than any of the login script mappings statements that refer to it.

  • Group—A Group object defines a list of users for the purpose of assigning access rights or other configuration parameters. The members of a group can be a subset of users in the same container or spread across multiple containers. The difference between containers and groups is that container objects store User objects, whereas Group objects store a list of User objects. Groups enable one of the great CNA tricks: they allow you to specify login script commands to a subset of users with the IF MEMBER OF syntax.

  • LDAP Group—An LDAP Group object stores configuration data (class mappings, attribute mappings, and security policies) for groups of LDAP Servers. During installation, an LDAP Group object named LDAP Group- <servername> is created by default in the host Server's home container.

  • LDAP Server—An LDAP Server object stores configuration data for a NetWare 6 server running LDAP Servers for eDirectory. During installation, an LDAP Server object named LDAP Server- <servername> is created by default in the host Server's home container. Make sure not to assign the same LDAP Server object to more than one server running LDAP Services for eDirectory.

  • License Certificate—A License Certificate object is used by NetWare Licensing Services (NLS) to monitor and control the use of licensed applications on the network. When the NLS-aware application is installed, a License Certificate object is added to the Licensed Product container.

  • NDPS Broker—An NDPS Broker provides three network support services for network printing: Service Registry Services (SRS), Event Notification Services (ENS), and Resource Management Services (RMS). When NDPS is installed, the installation utility ensures that a Broker object is loaded on your network.

  • NDPS Manager—The NDPS Manager is a logical entity used to create and manage NDPS Printers and Printer Agents. The NDPS Manager object stores information used by NDPSM.NLM on a single server. This single server can control multiple Printer Agents.

  • NDPS Printer—NDPS Printers magically transform electronic bits into written words. These objects are created by iManager as Controlled Access Printers. As eDirectory objects, NDPS Printers are no longer available as Public Access Printers.

  • Organizational Role—An Organizational Role object defines a position or role within the organization that can be filled by any designated user. The Organizational Role is particularly useful for rotating positions that support multiple employees, where the responsibilities of the job, and the network access required, are static. If a User object is assigned as an occupant of an organizational role, the user "absorbs" all trustee rights assigned to it. Some organizational role examples include PostMaster, Network Administrator, Silicon Valley CEO, or Receptionist.

  • Print Server (Non NDPS)—A Print Server (Non NDPS) object represents a network print server used for monitoring queue-based print queues and printers.

  • Printer (Non NDPS)—A Printer (Non NDPS) object represents a queue-based physical printing device on the network, such as a printer or plotter. Refer to Figure 3.7 for an illustration of the Printer (Non NDPS) properties that can be managed using ConsoleOne.

Figure 3.7Figure 3.7 Properties of an eDirectory Printer (Non NDPS) object.

  • Profile—A Profile object defines a login script for a subset of users in the same container or spread across multiple containers. (If all the users in a container need the same login script, you should use a Container login script, instead.)

  • Server—A Server object represents a server running eDirectory on your network. eDirectory supports the following operating system platforms: NetWare, Solaris, Linux, and/or Windows 2000. You can even create a Server object for Bindery servers running NetWare 2 or NetWare 3. This object is used by various leaf objects (such as Volume objects) to identify a physical server that provides particular network services. Refer to Figure 3.8 for an illustration of the Server properties that can be managed using ConsoleOne.

Figure 3.8Figure 3.8 Properties of an eDirectory Server object.

  • Unknown—An Unknown object represents an eDirectory object that has been corrupted, invalidated, or that cannot be identified as belonging to any of the other leaf classes. For example, an Alias object becomes Unknown when its host is deleted. Ouch!

  • User—A User object represents a person who uses the network (for example, you, me, or Fred). For security reasons, you should create a separate User object for each user on the network. A User object contains a plethora of interesting properties, including Login Name, Password, Full Name, Login Restrictions, and so on. Refer to Figure 3.9 for an illustration of the User properties that can be managed using ConsoleOne.

Figure 3.9Figure 3.9 Properties of an eDirectory User object.


eDirectory is a powerful database with much valuable user information. Consider using it as a central company database of employee data. If you can't find what you need in the almost 100 default properties, you can always create your own. The NetWare 6 Software Developers Kit (SDK) provides interface tools for modifying and adding eDirectory properties. This is called extending the eDirectory Schema.

In addition, NetWare 6 includes a Schema Manager for viewing and customizing the eDirectory Schema directly from ConsoleOne. You can access this GUI (graphical user interface) management tool from the Tools menu. Check it out...it's fun at parties!

  • Volume—A Volume object represents a physical volume on the network. Typically, volumes are created during the server installation process. Remember that a Volume object is a leaf object rather than a container object—even though the ConsoleOne utility may give you the opposite impression. It stores information about a volume, including server name, physical volume mapping, and volume use statistics. No information about files and folders on a volume is contained in a Volume object. However, you can access that information through ConsoleOne. Volume objects are supported only on NetWare. If you are using UNIX file system partitions, these cannot be managed using Volume objects.

  • Workstation—A Workstation object enables you to manage network workstations through eDirectory. This leaf object is automatically created when a workstation is registered and imported into the eDirectory tree.

Table 3.3 summarizes some important eDirectory object characteristics.

Table 3.3 eDirectory Object Characteristics





Tree Root (Required)

Top of the tree



Alias (of Country or Organization only)


Country (Optional)

Tree Root


Alias (of Organization only)



Organization (Required)

Tree Root Country



All leaf objects



Organizational Unit (Optional)


Organizational Unit

Organizational Units

All leaf objects



Leaf objects (Required and Optional)

Tree Root (Alias of Country or Organization only)

Country (Alias of Organization only)


Organizational Unit

Cannot contain other eDirectory objects




This completes the discussion of the most interesting eDirectory objects offered by NetWare 6. You'll want to get to know all these leaf objects because future discussions center around how to organize, design, and manage them. After you understand the relationships between eDirectory objects, you can start building your tree.


Every leaf object and container object is represented by an icon graphic that depicts its purpose. For example, printers are printers, servers are computers, and users are people. These icons are used throughout this book and in graphical eDirectory utilities. ConsoleOne, for example, uses icons to provide a snapshot of an entire eDirectory tree in a hierarchical structure. This feature makes it easier for administrators and users to locate and use NetWare 6 resources.

How do you feel? So far, you've explored all the physical and logical objects that make up NetWare 6's revolutionary eDirectory tree. However, this is only the beginning. Your success as a CNA is defined by your ability to manage eDirectory objects and their properties.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020