diff --git a/doc/admin-guide/configuration/proxy-protocol.en.rst b/doc/admin-guide/configuration/proxy-protocol.en.rst
index 64a0bc2fe2c..4be41ee1019 100644
--- a/doc/admin-guide/configuration/proxy-protocol.en.rst
+++ b/doc/admin-guide/configuration/proxy-protocol.en.rst
@@ -44,12 +44,12 @@ Proxy Protocol on a port.  Once enabled, all incoming requests must be prefaced
 with the PROXY v1 header.  Any request not preface by this header will be
 dropped.
 
-As a security measure, an optional whitelist of trusted IP addresses may be
+As a security measure, an optional allowlist of trusted IP addresses may be
 configured with :ts:cv:`proxy.config.http.proxy_protocol_whitelist`.
 
    .. important::
 
-       If the whitelist is configured, requests will only be accepted from these
+       If the allowlist is configured, requests will only be accepted from these
        IP addresses and must be prefaced with the PROXY v1 header.
 
 See :ts:cv:`proxy.config.http.insert_forwarded` for configuration information.
diff --git a/doc/admin-guide/files/records.config.en.rst b/doc/admin-guide/files/records.config.en.rst
index 2a24465f82d..29bc9e3f73c 100644
--- a/doc/admin-guide/files/records.config.en.rst
+++ b/doc/admin-guide/files/records.config.en.rst
@@ -1772,7 +1772,7 @@ Proxy User Variables
 
 .. ts:cv:: CONFIG proxy.config.http.proxy_protocol_whitelist STRING ```<ip list>```
 
-   This defines a whitelist of server IPs that are trusted to provide
+   This defines a allowlist of server IPs that are trusted to provide
    connections with Proxy Protocol information.  This is a comma delimited list
    of IP addresses.  Addressed may be listed individually, in a range separated
    by a dash or by using CIDR notation.
diff --git a/doc/admin-guide/plugins/cachekey.en.rst b/doc/admin-guide/plugins/cachekey.en.rst
index 9abf9ed0a29..dee6a77b6a4 100644
--- a/doc/admin-guide/plugins/cachekey.en.rst
+++ b/doc/admin-guide/plugins/cachekey.en.rst
@@ -179,10 +179,10 @@ Cache key structure and related plugin parameters
 ^^^^^^^^^^^^^^^
 
 * If no query related plugin parameters are used, the query string is included in the `cache key`.
-* ``--exclude-params`` (default: empty list) - comma-separated list of query params to be black-listed in the `cache key`. If the list is empty then no black-list is applied (no query parameters will be excluded from the `cache key`). The exclude list overrides the include list.
-* ``--include-params`` (default: empty list) - comma-separated list of query params to be white-listed in the `cache key`. If the list is empty then no white-list is applied (all query parameters will be included in the `cache key`).
-* ``--include-match-params`` (default: empty list) - regular expression matching query parameter names which will be white-listed in the `cache key`.
-* ``--exclude-match-params`` (default: empty list) - regular expression matching query parameter names which will be black-listed in the `cache key`.
+* ``--exclude-params`` (default: empty list) - comma-separated list of query params to be block-listed in the `cache key`. If the list is empty then no block-list is applied (no query parameters will be excluded from the `cache key`). The exclude list overrides the include list.
+* ``--include-params`` (default: empty list) - comma-separated list of query params to be allow-listed in the `cache key`. If the list is empty then no allow-list is applied (all query parameters will be included in the `cache key`).
+* ``--include-match-params`` (default: empty list) - regular expression matching query parameter names which will be allow-listed in the `cache key`.
+* ``--exclude-match-params`` (default: empty list) - regular expression matching query parameter names which will be block-listed in the `cache key`.
 * ``--remove-all-params`` (boolean:``true|false``, ``0|1``, ``yes|no``, default: ``false``) - if equals ``true`` then all query parameters are removed (the whole query string) and all other URI query parameter related settings (if used) will have no effect.
 * ``--sort-params`` (boolean:``true|false``, ``0|1``, ``yes|no``, default: ``false``) - if equals ``true`` then all query parameters are sorted in an increasing case-sensitive order
 
@@ -377,7 +377,7 @@ The following will make sure only query parameters ``a`` and ``c`` will be used
 
 If the URI has the following query string ``c=1&a=1&b=2&x=1&k=1&u=1&y=1`` the `cache key` will use ``c=1&a=1``
 
-White-list + black-list certain parameters using multiple parameters in the same remap rule.
+Allow-list + block-list certain parameters using multiple parameters in the same remap rule.
 """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 If the plugin is used with the following plugin parameters in the remap rule: ::
 
@@ -390,7 +390,7 @@ If the plugin is used with the following plugin parameters in the remap rule: ::
 
 and if the URI has the following query string ``c=1&a=1&b=2&x=1&k=1&u=1&y=1`` the `cache key` will use ``c=1&b=1``
 
-White-list + black-list certain parameters using multiple parameters in the same remap rule and regular expressions (PCRE).
+Allow-list + block-list certain parameters using multiple parameters in the same remap rule and regular expressions (PCRE).
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 If the plugin is used with the following plugin parameters in the remap rule: ::
 
@@ -570,7 +570,7 @@ If the plugin is used with the following plugin parameter::
 
 then ``Mozilla/5.0_AppleWebKit/537.75.14`` will be used when constructing the key.
 
-User-Agent white-list classifier
+User-Agent allow-list classifier
 """"""""""""""""""""""""""""""""
 If the plugin is used with the following plugin parameter::
 
@@ -585,7 +585,7 @@ and if ``browser_agents.config`` contains: ::
 
 then ``browser`` will be used when constructing the key.
 
-User-Agent black-list classifier
+User-Agent block-list classifier
 """"""""""""""""""""""""""""""""
 If the plugin is used with the following plugin parameter::
 
diff --git a/doc/developer-guide/api/functions/TSAPI.en.rst b/doc/developer-guide/api/functions/TSAPI.en.rst
index b47d0ec1136..3b4eba490b9 100644
--- a/doc/developer-guide/api/functions/TSAPI.en.rst
+++ b/doc/developer-guide/api/functions/TSAPI.en.rst
@@ -59,11 +59,11 @@ type.
 
 Possible uses for plugins include the following:
 
-* HTTP processing plugins can filter, blacklist, authorize users or transform content.
+* HTTP processing plugins can filter, blocklist, authorize users or transform content.
 
 * Protocol plugins can enable Traffic Server to proxy-cache new protocol content.
 
-* A blacklisting plugin denies attempts to access web sites that are off-limits.
+* A blocklisting plugin denies attempts to access web sites that are off-limits.
 
 * Append transform plugins add data to HTTP response content.
 
diff --git a/doc/developer-guide/introduction/index.en.rst b/doc/developer-guide/introduction/index.en.rst
index 19c43814efb..1f9515936ae 100644
--- a/doc/developer-guide/introduction/index.en.rst
+++ b/doc/developer-guide/introduction/index.en.rst
@@ -53,7 +53,7 @@ Below is a section-by-section breakdown of this guide:
    How to compile and load plugins. Walks through a simple "hello world"
    example; explains how to initialize and register plugins. Basic structures
    that all plugins use: events, continuations, and how to hook on to |TS|
-   processes. Detailed explication of a sample blacklisting plugin.
+   processes. Detailed explication of a sample blocklisting plugin.
 
 :ref:`developer-plugins-examples-query-remap`
    This chapter demonstrates on a practical example how you can
@@ -61,7 +61,7 @@ Below is a section-by-section breakdown of this guide:
 
 :ref:`developer-plugins-header-based-examples`
    Detailed explanation about writing plugins that work on HTTP
-   headers; discusses sample blacklisting and basic authorization
+   headers; discusses sample blocklisting and basic authorization
    plugins.
 
 :ref:`developer-plugins-http-transformations`
diff --git a/doc/developer-guide/plugins/example-plugins/blacklist/accessing-the-transaction-being-processed.en.rst b/doc/developer-guide/plugins/example-plugins/blocklist/accessing-the-transaction-being-processed.en.rst
similarity index 91%
rename from doc/developer-guide/plugins/example-plugins/blacklist/accessing-the-transaction-being-processed.en.rst
rename to doc/developer-guide/plugins/example-plugins/blocklist/accessing-the-transaction-being-processed.en.rst
index 46d2a54a41d..baf73e24910 100644
--- a/doc/developer-guide/plugins/example-plugins/blacklist/accessing-the-transaction-being-processed.en.rst
+++ b/doc/developer-guide/plugins/example-plugins/blocklist/accessing-the-transaction-being-processed.en.rst
@@ -17,7 +17,7 @@
 
 .. include:: ../../../../common.defs
 
-.. _developer-plugins-blacklist-access-process-txn:
+.. _developer-plugins-blocklist-access-process-txn:
 
 Accessing the Transaction Being Processed
 *****************************************
@@ -38,12 +38,12 @@ The key here is that if the event is an HTTP transaction event, then the
 data passed to the continuation's handler is of type ``TSHttpTxn`` (a
 data type that represents HTTP transactions). Your plugin can then do
 things with the transaction. Here's how it looks in the code for the
-Blacklist plugin's handler:
+Blocklist plugin's handler:
 
 .. code-block:: c
 
    static int
-   blacklist_plugin (TSCont contp, TSEvent event, void *edata)
+   blocklist_plugin (TSCont contp, TSEvent event, void *edata)
    {
       TSHttpTxn txnp = (TSHttpTxn) edata;
       switch (event) {
@@ -60,5 +60,5 @@ Blacklist plugin's handler:
    }
 
 For example: when the origin server DNS lookup event is sent,
-``blacklist_plugin`` can call ``handle_dns``\ and pass ``txnp`` as an
+``blocklist_plugin`` can call ``handle_dns``\ and pass ``txnp`` as an
 argument.
diff --git a/doc/developer-guide/plugins/example-plugins/blacklist/index.en.rst b/doc/developer-guide/plugins/example-plugins/blocklist/index.en.rst
similarity index 77%
rename from doc/developer-guide/plugins/example-plugins/blacklist/index.en.rst
rename to doc/developer-guide/plugins/example-plugins/blocklist/index.en.rst
index b88c3f288fc..2bdfc00b12b 100644
--- a/doc/developer-guide/plugins/example-plugins/blacklist/index.en.rst
+++ b/doc/developer-guide/plugins/example-plugins/blocklist/index.en.rst
@@ -17,21 +17,21 @@
 
 .. include:: ../../../../common.defs
 
-.. _developer-plugins-examples-blacklist:
+.. _developer-plugins-examples-blocklist:
 
-Blacklist Plugin
+Blocklist Plugin
 ****************
 
-The sample blacklisting plugin included in the Traffic Server SDK is
-``blacklist_1.c``. This plugin checks every incoming HTTP client request
-against a list of blacklisted web sites. If the client requests a
-blacklisted site, then the plugin returns an ``Access forbidden``
+The sample blocklisting plugin included in the Traffic Server SDK is
+``blocklist_1.c``. This plugin checks every incoming HTTP client request
+against a list of blocklisted web sites. If the client requests a
+blocklisted site, then the plugin returns an ``Access forbidden``
 message to the client.
 
-The flow of HTTP processing with the blacklist plugin is illustrated in
-the figure titled :ref:`BlackListPlugin`.
+The flow of HTTP processing with the blocklist plugin is illustrated in
+the figure titled :ref:`BlockListPlugin`.
 This example also contains a simple configuration management interface.
-It can read a list of blacklisted sites from a file (``blacklist.txt``)
+It can read a list of blocklisted sites from a file (``blocklist.txt``)
 that can be updated by a Traffic Server administrator. When the
 configuration file is updated, Traffic Server sends an event to the
 plugin that wakes it up to do some work.
@@ -52,7 +52,7 @@ Traffic Server has a multi-threaded design, race conditions can occur if
 several threads try to access the same continuation's data.
 
 Here is how the static parent continuation is created in
-``blacklist_1.c``:
+``blocklist_1.c``:
 
 .. code-block:: c
 
@@ -62,20 +62,20 @@ Here is how the static parent continuation is created in
       // ...
       TSCont contp;
 
-      contp = TSContCreate (blacklist_plugin, NULL);
+      contp = TSContCreate (blocklist_plugin, NULL);
       // ...
    }
 
-The handler function for the plugin is ``blacklist_plugin``, and the
+The handler function for the plugin is ``blocklist_plugin``, and the
 mutex is null. The continuation handler function's job is to handle the
-events that are sent to it; accordingly, the ``blacklist_plugin``
+events that are sent to it; accordingly, the ``blocklist_plugin``
 routine consists of a switch statement that covers each of the events
 that might be sent to it:
 
 .. code-block:: c
 
    static int
-   blacklist_plugin (TSCont contp, TSEvent event, void *edata)
+   blocklist_plugin (TSCont contp, TSEvent event, void *edata)
    {
       TSHttpTxn txnp = (TSHttpTxn) edata;
       switch (event) {
@@ -86,7 +86,7 @@ that might be sent to it:
             handle_response (txnp);
             return 0;
          default:
-            TSDebug ("blacklist_plugin", "This event was unexpected: %d", );
+            TSDebug ("blocklist_plugin", "This event was unexpected: %d", );
             break;
       }
       return 0;
@@ -94,10 +94,10 @@ that might be sent to it:
 
 When you write handler functions, you have to anticipate any events that
 might be sent to the handler by hooks or by other functions. In the
-Blacklist plugin, ``TS_EVENT_OS_DNS`` is sent because of the global hook
+Blocklist plugin, ``TS_EVENT_OS_DNS`` is sent because of the global hook
 established in ``TSPluginInit``, ``TS_EVENT_HTTP_SEND_RESPONSE_HDR`` is
 sent because the plugin contains a transaction hook
-(see :ref:`developer-plugins-examples-blacklist-txn-hook`).
+(see :ref:`developer-plugins-examples-blocklist-txn-hook`).
 It is good practice to have a default case in your switch statements.
 
 .. toctree::
diff --git a/doc/developer-guide/plugins/example-plugins/blacklist/setting-a-global-hook.en.rst b/doc/developer-guide/plugins/example-plugins/blocklist/setting-a-global-hook.en.rst
similarity index 87%
rename from doc/developer-guide/plugins/example-plugins/blacklist/setting-a-global-hook.en.rst
rename to doc/developer-guide/plugins/example-plugins/blocklist/setting-a-global-hook.en.rst
index e471b1c5d2d..fe5924d09c2 100644
--- a/doc/developer-guide/plugins/example-plugins/blacklist/setting-a-global-hook.en.rst
+++ b/doc/developer-guide/plugins/example-plugins/blocklist/setting-a-global-hook.en.rst
@@ -23,7 +23,7 @@ Setting a Global Hook
 Global hooks are always added in ``TSPluginInit`` using
 ``TSHttpHookAdd``. The two arguments of ``TSHttpHookAdd`` are the hook
 ID and the continuation to call when processing the event corresponding
-to the hook. In ``blacklist_1.c``, the global hook is added as follows:
+to the hook. In ``blocklist_1.c``, the global hook is added as follows:
 
 .. code-block:: c
 
@@ -32,7 +32,7 @@ to the hook. In ``blacklist_1.c``, the global hook is added as follows:
 Above, ``TS_HTTP_OS_DNS_HOOK`` is the ID for the origin server DNS
 lookup hook and ``contp`` is the parent continuation created earlier.
 
-This means that the Blacklist plugin is called at every origin server
-DNS lookup. When it is called, the handler functio ``blacklist_plugin``
+This means that the Blocklist plugin is called at every origin server
+DNS lookup. When it is called, the handler functio ``blocklist_plugin``
 receives ``TS_EVENT_HTTP_OS_DNS`` and calls ``handle_dns`` to see if the
 request is forbidden.
diff --git a/doc/developer-guide/plugins/example-plugins/blacklist/setting-up-a-transaction-hook.en.rst b/doc/developer-guide/plugins/example-plugins/blocklist/setting-up-a-transaction-hook.en.rst
similarity index 83%
rename from doc/developer-guide/plugins/example-plugins/blacklist/setting-up-a-transaction-hook.en.rst
rename to doc/developer-guide/plugins/example-plugins/blocklist/setting-up-a-transaction-hook.en.rst
index 7f89d31c054..72f663493b9 100644
--- a/doc/developer-guide/plugins/example-plugins/blacklist/setting-up-a-transaction-hook.en.rst
+++ b/doc/developer-guide/plugins/example-plugins/blocklist/setting-up-a-transaction-hook.en.rst
@@ -17,16 +17,16 @@
 
 .. include:: ../../../../common.defs
 
-.. _developer-plugins-examples-blacklist-txn-hook:
+.. _developer-plugins-examples-blocklist-txn-hook:
 
 Setting Up a Transaction Hook
 *****************************
 
-The Blacklist plugin sends "access forbidden" messages to clients if
-their requests are directed to blacklisted hosts. Therefore, the plugin
+The Blocklist plugin sends "access forbidden" messages to clients if
+their requests are directed to blocklisted hosts. Therefore, the plugin
 needs a transaction hook so it will be called back when Traffic Server's
 HTTP state machine reaches the "send response header" event. In the
-Blacklist plugin's ``handle_dns`` routine, the transaction hook is added
+Blocklist plugin's ``handle_dns`` routine, the transaction hook is added
 as follows:
 
 .. code-block:: c
@@ -34,7 +34,7 @@ as follows:
    TSMutexLock (sites_mutex);
    for (i = 0; i < nsites; i++) {
       if (strncmp (host, sites[i], host_length) == 0) {
-         printf ("blacklisting site: %s\n", sites[i]);
+         printf ("blocklisting site: %s\n", sites[i]);
          TSHttpTxnHookAdd (txnp,
             TS_HTTP_SEND_RESPONSE_HDR_HOOK,
             contp);
@@ -50,10 +50,10 @@ as follows:
    TSHttpTxnReenable (txnp, TS_EVENT_HTTP_CONTINUE);
 
 This code fragment shows some interesting features. The plugin is
-comparing the requested site to the list of blacklisted sites. While the
-plugin is using the blacklist, it must acquire the mutex lock for the
-blacklist to prevent configuration changes in the middle of a
-blacklisting operation. If the requested site is blacklisted, then the
+comparing the requested site to the list of blocklisted sites. While the
+plugin is using the blocklist, it must acquire the mutex lock for the
+blocklist to prevent configuration changes in the middle of a
+blocklisting operation. If the requested site is blocklisted, then the
 following things happen:
 
 #. A transaction hook is added with ``TSHttpTxnHookAdd``; the plugin is
@@ -66,7 +66,7 @@ following things happen:
    ``TS_EVENT_HTTP_ERROR`` as its event argument. Reenabling with an
    error event tells the HTTP state machine to stop the transaction and
    jump to the "send response header" state. Notice that if the
-   requested site is not blacklisted, then the transaction is reenabled
+   requested site is not blocklisted, then the transaction is reenabled
    with the ``TS_EVENT_HTTP_CONTINUE`` event.
 
 #. The string and ``TSMLoc`` data stored in the marshal buffer ``bufp`` is
diff --git a/doc/developer-guide/plugins/example-plugins/blacklist/source-code.en.rst b/doc/developer-guide/plugins/example-plugins/blocklist/source-code.en.rst
similarity index 73%
rename from doc/developer-guide/plugins/example-plugins/blacklist/source-code.en.rst
rename to doc/developer-guide/plugins/example-plugins/blocklist/source-code.en.rst
index 0be18042423..e43a026bf50 100644
--- a/doc/developer-guide/plugins/example-plugins/blacklist/source-code.en.rst
+++ b/doc/developer-guide/plugins/example-plugins/blocklist/source-code.en.rst
@@ -17,20 +17,20 @@
 
 .. include:: ../../../../common.defs
 
-.. _developer-plugins-examples-blacklist-code:
+.. _developer-plugins-examples-blocklist-code:
 
 Sample Source Code
 ******************
 
-.. _blacklist-1.c:
+.. _blocklist-1.c:
 
-blacklist_1.c
+blocklist_1.c
 -------------
 
-The sample blacklisting plugin included in the Traffic Server SDK is
-``blacklist_1.c``. This plugin checks every incoming HTTP client request
-against a list of blacklisted web sites. If the client requests a
-blacklisted site, then the plugin returns an ``Access forbidden``
+The sample blocklisting plugin included in the Traffic Server SDK is
+``blocklist_1.c``. This plugin checks every incoming HTTP client request
+against a list of blocklisted web sites. If the client requests a
+blocklisted site, then the plugin returns an ``Access forbidden``
 message to the client.
 
 This plugin illustrates:
@@ -43,5 +43,5 @@ This plugin illustrates:
 
 -  How to use the plugin configuration management interface
 
-.. literalinclude:: ../../../../../example/plugins/c-api/blacklist_1/blacklist_1.c
+.. literalinclude:: ../../../../../example/plugins/c-api/blocklist_1/blocklist_1.c
    :language: c
diff --git a/doc/developer-guide/plugins/example-plugins/blacklist/working-with-http-header-functions.en.rst b/doc/developer-guide/plugins/example-plugins/blocklist/working-with-http-header-functions.en.rst
similarity index 86%
rename from doc/developer-guide/plugins/example-plugins/blacklist/working-with-http-header-functions.en.rst
rename to doc/developer-guide/plugins/example-plugins/blocklist/working-with-http-header-functions.en.rst
index 5d394606306..86dfa64df3b 100644
--- a/doc/developer-guide/plugins/example-plugins/blacklist/working-with-http-header-functions.en.rst
+++ b/doc/developer-guide/plugins/example-plugins/blocklist/working-with-http-header-functions.en.rst
@@ -17,12 +17,12 @@
 
 .. include:: ../../../../common.defs
 
-.. _developer-plugins-examples-blacklist-http-header-functions:
+.. _developer-plugins-examples-blocklist-http-header-functions:
 
 Working with HTTP Header Functions
 **********************************
 
-The Blacklist plugin examines the host header in every client
+The Blocklist plugin examines the host header in every client
 transaction. This is done in the ``handle_dns`` routine, using
 ``TSHttpTxnClientReqGet``, ``TSHttpHdrUrlGet``, and ``TSUrlHostGet``.
 
@@ -39,19 +39,19 @@ transaction. This is done in the ``handle_dns`` routine, using
    int host_length;
 
    if (TSHttpTxnClientReqGet(txnp, &bufp, &hdr_loc) != TS_SUCCESS) {
-      TSError("[blacklist] Couldn't retrieve client request header");
+      TSError("[blocklist] Couldn't retrieve client request header");
       goto done;
    }
 
    if (TSHttpHdrUrlGet(bufp, hdr_loc, &url_loc) != TS_SUCCESS) {
-      TSError("[blacklist] Couldn't retrieve request url");
+      TSError("[blocklist] Couldn't retrieve request url");
       TSHandleMLocRelease(bufp, TS_NULL_MLOC, hdr_loc);
       goto done;
    }
 
    host = TSUrlHostGet(bufp, url_loc, &host_length);
    if (!host) {
-      TSError("[blacklist] couldn't retrieve request hostname");
+      TSError("[blocklist] couldn't retrieve request hostname");
       TSHandleMLocRelease(bufp, hdr_loc, url_loc);
       TSHandleMLocRelease(bufp, TS_NULL_MLOC, hdr_loc);
       goto done;
diff --git a/doc/developer-guide/plugins/example-plugins/index.en.rst b/doc/developer-guide/plugins/example-plugins/index.en.rst
index 7da4a35ee69..b0e0799392f 100644
--- a/doc/developer-guide/plugins/example-plugins/index.en.rst
+++ b/doc/developer-guide/plugins/example-plugins/index.en.rst
@@ -26,7 +26,7 @@ Example Plugins
    :maxdepth: 2
 
    basic-authorization/index.en
-   blacklist/index.en
+   blocklist/index.en
    query_remap/index.en
    tls_bridge.en
 
@@ -47,7 +47,7 @@ understand the following topics:
 
 -  Working with HTTP header functions
 
-The two sample plugins discussed in this chapter are ``blacklist_1.c``
+The two sample plugins discussed in this chapter are ``blocklist_1.c``
 and ``basic_auth.c``. To build and install the example plugins use ::
 
    ./configure --enable-example-plugins
diff --git a/doc/developer-guide/plugins/getting-started/index.en.rst b/doc/developer-guide/plugins/getting-started/index.en.rst
index b4a482feddf..8867223507e 100644
--- a/doc/developer-guide/plugins/getting-started/index.en.rst
+++ b/doc/developer-guide/plugins/getting-started/index.en.rst
@@ -93,7 +93,7 @@ Possible Uses for Plugins
 
 Possible uses for plugins include the following:
 
--  HTTP processing: plugins can filter, blacklist, authorize users,
+-  HTTP processing: plugins can filter, blocklist, authorize users,
    transform content
 
 -  Protocol support: plugins can enable Traffic Server to proxy-cache
@@ -101,7 +101,7 @@ Possible uses for plugins include the following:
 
 Some examples of plugins include:
 
--  **Blacklisting plugin**: denies attempts to access web sites that are
+-  **Blocklisting plugin**: denies attempts to access web sites that are
    off-limits.
 
 -  **Append transform plugin**: adds text to HTTP response content.
@@ -151,9 +151,9 @@ You can find basic examples for many plugins in the SDK sample code:
 
 -  ``basic_auth.c`` performs basic HTTP proxy authorization.
 
--  ``blacklist_1.c`` reads blacklisted servers from a configuration file
+-  ``blocklist_1.c`` reads blocklisted servers from a configuration file
    and denies client access to these servers. This plugin is explained
-   in :ref:`developer-plugins-examples-blacklist`.
+   in :ref:`developer-plugins-examples-blocklist`.
 
 Plugin Loading
 --------------
diff --git a/doc/developer-guide/plugins/hooks-and-transactions/adding-hooks.en.rst b/doc/developer-guide/plugins/hooks-and-transactions/adding-hooks.en.rst
index e6174314723..074ed4a8b55 100644
--- a/doc/developer-guide/plugins/hooks-and-transactions/adding-hooks.en.rst
+++ b/doc/developer-guide/plugins/hooks-and-transactions/adding-hooks.en.rst
@@ -33,7 +33,7 @@ There are several ways to add hooks to your plugin.
 -  **Transaction hooks** Transaction hooks can be used to call plugins
    back for a specific HTTP transaction. You cannot add transaction
    hooks in ``TSPluginInit``; you first need a handle to a transaction.
-   See :ref:`developer-plugins-blacklist-access-process-txn`.
+   See :ref:`developer-plugins-blocklist-access-process-txn`.
 
 -  **Transformation hooks** Transformation hooks are a special case of
    transaction hooks. See
@@ -80,7 +80,7 @@ values for ``TSHttpHookID`` are:
     Called immediately after the HTTP state machine has completed a DNS
     lookup of the origin server. The HTTP state machine will know the
     origin server's IP address at this point, which is useful for
-    performing both authentication and blacklisting. Corresponds to the
+    performing both authentication and blocklisting. Corresponds to the
     event ``TS_EVENT_HTTP_OS_DNS``.
 
 ``TS_HTTP_POST_REMAP_HOOK``
diff --git a/doc/developer-guide/plugins/http-headers/trafficserver-http-header-system.en.rst b/doc/developer-guide/plugins/http-headers/trafficserver-http-header-system.en.rst
index 6af66bcc633..dc2d432898c 100644
--- a/doc/developer-guide/plugins/http-headers/trafficserver-http-header-system.en.rst
+++ b/doc/developer-guide/plugins/http-headers/trafficserver-http-header-system.en.rst
@@ -42,7 +42,7 @@ passed into the common ``str*()`` routines
    Values returned from a marshall buffer can be ``NULL``, which means the
    field or object requested does not exist.
 
-For example (from the ``blacklist_1`` sample)
+For example (from the ``blocklist_1`` sample)
 
 .. code-block:: c
 
diff --git a/doc/developer-guide/plugins/introduction.en.rst b/doc/developer-guide/plugins/introduction.en.rst
index 58aaf32860d..0cca78956ad 100644
--- a/doc/developer-guide/plugins/introduction.en.rst
+++ b/doc/developer-guide/plugins/introduction.en.rst
@@ -173,7 +173,7 @@ them into activity.
 
 A plugin may consist of just one static continuation that is called
 whenever certain events happen. Examples of such plugins include
-``blacklist_1.c``, ``basic_auth.c``, and ``redirect_1.c``.
+``blocklist_1.c``, ``basic_auth.c``, and ``redirect_1.c``.
 Alternatively, a plugin might dynamically create other continuations as
 needed. Transform plugins are built in this manner: a static parent
 continuation checks all transactions to see if any are transformable;
@@ -266,35 +266,35 @@ reflects the Traffic Server state that was *just completed*. For
 example, the "OS DNS lookup" hook wakes up a plugin right *after* the
 origin server DNS lookup. For a plugin that requires the IP address of
 the requested origin server, this hook is the right one to use. The
-Blacklist plugin works in this manner, as shown in the :ref:`BlackListPlugin`
+Blocklist plugin works in this manner, as shown in the :ref:`BlockListPlugin`
 diagram below.
 
-**Blacklist Plugin**
+**Blocklist Plugin**
 
-.. _BlackListPlugin:
+.. _BlockListPlugin:
 
-.. figure:: /static/images/sdk/blacklist75.jpg
-   :alt: Blacklist Plugin
+.. figure:: /static/images/sdk/blocklist75.jpg
+   :alt: Blocklist Plugin
 
-   Blacklist Plugin
+   Blocklist Plugin
 
-Traffic Server calls the Blacklist plugin right after the origin server
+Traffic Server calls the Blocklist plugin right after the origin server
 DNS lookup. The plugin checks the requested host against a list of
-blacklisted servers; if the request is allowed, then the transaction
-proceeds. If the host is forbidden, then the Blacklist plugin sends the
+blocklisted servers; if the request is allowed, then the transaction
+proceeds. If the host is forbidden, then the Blocklist plugin sends the
 transaction into an error state. When the HTTP state machine gets to the
-"send reply header" state, it then calls the Blacklist plugin to provide
+"send reply header" state, it then calls the Blocklist plugin to provide
 the error message that's sent to the client.
 
 Types of Hooks
 ^^^^^^^^^^^^^^
 
-The Blacklist plugin's hook to the origin server DNS lookup state is a *global
+The Blocklist plugin's hook to the origin server DNS lookup state is a *global
 hook*, meaning that the plugin is called every time there's an HTTP transaction
 with a DNS lookup event. The plugin's hook to the send reply header state is a
 *transaction hook*, meaning that this hook is only invoked for specified
-transactions (in the :ref:`developer-plugins-examples-blacklist` example, it's
-only used for requests to blacklisted servers). Several examples of setting up
+transactions (in the :ref:`developer-plugins-examples-blocklist` example, it's
+only used for requests to blocklisted servers). Several examples of setting up
 hooks are provided in :ref:`developer-plugins-header-based-examples` and
 :ref:`developer-plugins-http-transformations`.
 
diff --git a/doc/developer-guide/plugins/mutexes.en.rst b/doc/developer-guide/plugins/mutexes.en.rst
index 6c63c0d053a..accd0e917b3 100644
--- a/doc/developer-guide/plugins/mutexes.en.rst
+++ b/doc/developer-guide/plugins/mutexes.en.rst
@@ -71,12 +71,12 @@ by other continuations).
 Locking Global Data
 ===================
 
-The :ref:`blacklist-1.c` sample plugin implements a mutex that locks global
-data. The blacklist plugin reads its blacklisted sites from a
+The :ref:`blocklist-1.c` sample plugin implements a mutex that locks global
+data. The blocklist plugin reads its blocklisted sites from a
 configuration file; file read operations are protected by a mutex
-created in :c:func:`TSPluginInit`. The :ref:`blacklist-1.c` code uses
+created in :c:func:`TSPluginInit`. The :ref:`blocklist-1.c` code uses
 :c:func:`TSMutexLockTry` instead of :c:func:`TSMutexLock`. For more detailed
-information, see the :ref:`blacklist-1.c` code;
+information, see the :ref:`blocklist-1.c` code;
 start by looking at the :c:func:`TSPluginInit` function.
 
 General guidelines for locking shared data are as follows:
diff --git a/doc/developer-guide/plugins/plugin-management/logging-api.en.rst b/doc/developer-guide/plugins/plugin-management/logging-api.en.rst
index 0ce902b2985..8503fd04f7e 100644
--- a/doc/developer-guide/plugins/plugin-management/logging-api.en.rst
+++ b/doc/developer-guide/plugins/plugin-management/logging-api.en.rst
@@ -58,8 +58,8 @@ The logging API enables you to:
    :c:func:`TSTextLogObjectDestroy`
 
 The steps below show how the logging API is used in the
-``blacklist_1.c`` sample plugin. For the complete source code, see the
-:ref:`developer-plugins-examples-blacklist-code` section.
+``blocklist_1.c`` sample plugin. For the complete source code, see the
+:ref:`developer-plugins-examples-blocklist-code` section.
 
 #. A new log file is defined as a global variable.
 
@@ -71,10 +71,10 @@ The steps below show how the logging API is used in the
 
    .. code-block:: c
 
-           TSReturnCode error = TSTextLogObjectCreate("blacklist",
+           TSReturnCode error = TSTextLogObjectCreate("blocklist",
                                 TS_LOG_MODE_ADD_TIMESTAMP, &log);
 
-   The new log is named ``blacklist.log``. Each entry written to the log
+   The new log is named ``blocklist.log``. Each entry written to the log
    will have a timestamp. The ``NULL`` argument specifies that the new
    log does not have a log header. The error argument stores the result
    of the log creation; if the log is created successfully, then an
@@ -86,11 +86,11 @@ The steps below show how the logging API is used in the
    .. code-block:: c
 
        if (error != TS_SUCCESS) {
-           printf("Blacklist plugin: error %d while creating log\n", error);
+           printf("Blocklist plugin: error %d while creating log\n", error);
        }
 
-#. The :ref:`developer-plugins-examples-blacklist` matches the host portion of
-   the URL (in each client request) with a list of blacklisted sites (stored in
+#. The :ref:`developer-plugins-examples-blocklist` matches the host portion of
+   the URL (in each client request) with a list of blocklisted sites (stored in
    the array ``sites[]``):
 
    .. code-block:: c
@@ -101,23 +101,23 @@ The steps below show how the logging API is used in the
          }
        }
 
-   If the host matches one of the blacklisted
-   sites (such as ``sites[i]``), then the plugin writes a blacklist
-   entry to ``blacklist.log``:
+   If the host matches one of the blocklisted
+   sites (such as ``sites[i]``), then the plugin writes a blocklist
+   entry to ``blocklist.log``:
 
    .. code-block:: c
 
-       if (log) { TSTextLogObjectWrite(log, "blacklisting site: %s",
+       if (log) { TSTextLogObjectWrite(log, "blocklisting site: %s",
        sites[i]);
 
    The format of the log entry is as follows:
 
    ::
 
-       blacklisting site: sites[i]
+       blocklisting site: sites[i]
 
    The log is not flushed or
-   destroyed in the ``blacklist_1`` plugin - it lives for the life of
+   destroyed in the ``blocklist_1`` plugin - it lives for the life of
    the plugin.
 
 
diff --git a/doc/static/images/sdk/blacklist75.jpg b/doc/static/images/sdk/blocklist75.jpg
similarity index 100%
rename from doc/static/images/sdk/blacklist75.jpg
rename to doc/static/images/sdk/blocklist75.jpg
diff --git a/example/plugins/c-api/blacklist_0/blacklist_0.c b/example/plugins/c-api/blocklist_0/blocklist_0.c
similarity index 93%
rename from example/plugins/c-api/blacklist_0/blacklist_0.c
rename to example/plugins/c-api/blocklist_0/blocklist_0.c
index 5ca5179e1fb..a7da67c69a2 100644
--- a/example/plugins/c-api/blacklist_0/blacklist_0.c
+++ b/example/plugins/c-api/blocklist_0/blocklist_0.c
@@ -22,8 +22,8 @@
  */
 
 /*
- *   blacklist_0.c:
- *	original version of blacklist-1, now used for internal testing
+ *   blocklist_0.c:
+ *	original version of blocklist-1, now used for internal testing
  *
  *
  *	Usage:
@@ -34,7 +34,7 @@
 #include <string.h>
 #include <ts/ts.h>
 
-#define PLUGIN_NAME "blacklist_0"
+#define PLUGIN_NAME "blocklist_0"
 
 static char **sites;
 static int nsites;
@@ -69,7 +69,7 @@ handle_dns(TSHttpTxn txnp, TSCont contp)
   }
   for (i = 0; i < nsites; i++) {
     if (strncmp(host, sites[i], host_length) == 0) {
-      printf("blacklisting site: %s\n", sites[i]);
+      printf("blocklisting site: %s\n", sites[i]);
       TSHttpTxnHookAdd(txnp, TS_HTTP_SEND_RESPONSE_HDR_HOOK, contp);
       TSHandleMLocRelease(bufp, hdr_loc, url_loc);
       TSHandleMLocRelease(bufp, TS_NULL_MLOC, url_loc);
@@ -130,7 +130,7 @@ handle_response(TSHttpTxn txnp)
 }
 
 static int
-blacklist_plugin(TSCont contp, TSEvent event, void *edata)
+blocklist_plugin(TSCont contp, TSEvent event, void *edata)
 {
   TSHttpTxn txnp = (TSHttpTxn)edata;
 
@@ -168,6 +168,6 @@ TSPluginInit(int argc, const char *argv[])
       sites[i] = TSstrdup(argv[i + 1]);
     }
 
-    TSHttpHookAdd(TS_HTTP_OS_DNS_HOOK, TSContCreate(blacklist_plugin, NULL));
+    TSHttpHookAdd(TS_HTTP_OS_DNS_HOOK, TSContCreate(blocklist_plugin, NULL));
   }
 }
diff --git a/example/plugins/c-api/blacklist_1/blacklist.txt b/example/plugins/c-api/blocklist_1/blocklist.txt
similarity index 100%
rename from example/plugins/c-api/blacklist_1/blacklist.txt
rename to example/plugins/c-api/blocklist_1/blocklist.txt
diff --git a/example/plugins/c-api/blacklist_1/blacklist_1.c b/example/plugins/c-api/blocklist_1/blocklist_1.c
similarity index 100%
rename from example/plugins/c-api/blacklist_1/blacklist_1.c
rename to example/plugins/c-api/blocklist_1/blocklist_1.c
diff --git a/example/plugins/c-api/blacklist_1/readme.txt b/example/plugins/c-api/blocklist_1/readme.txt
similarity index 100%
rename from example/plugins/c-api/blacklist_1/readme.txt
rename to example/plugins/c-api/blocklist_1/readme.txt