From 2df6547c8abf277afa6f71afc36d2b3ebb41101e Mon Sep 17 00:00:00 2001
From: Paul Wright <pwright@redhat.com>
Date: Thu, 28 Mar 2024 17:44:53 +0000
Subject: [PATCH] fix formats

---
 docs/docs/cli/index.html                      | 30 +++++++++----------
 docs/docs/cli/native-security-options.html    | 10 +++----
 docs/docs/cli/podman.html                     | 10 +++----
 input/docs/cli/index.md                       | 30 +++++++++----------
 input/docs/cli/native-security-options.md     |  8 ++---
 input/docs/cli/podman.md                      | 10 +++----
 subrepos/skupper-docs/cli/gateway.adoc        | 10 +++----
 subrepos/skupper-docs/cli/index.adoc          | 10 +++----
 subrepos/skupper-docs/cli/link-cost.adoc      |  2 +-
 .../cli/native-security-options.adoc          |  6 ++--
 subrepos/skupper-docs/cli/network-status.adoc |  2 +-
 subrepos/skupper-docs/cli/podman.adoc         |  2 +-
 subrepos/skupper-docs/cli/protocols.adoc      |  2 +-
 13 files changed, 66 insertions(+), 66 deletions(-)

diff --git a/docs/docs/cli/index.html b/docs/docs/cli/index.html
index 2d55dda8..630dce25 100644
--- a/docs/docs/cli/index.html
+++ b/docs/docs/cli/index.html
@@ -250,7 +250,7 @@ <h2 id="specifying-link-cost">Specifying link cost</h2>
 For example, in a two site network linked with a high cost with servers and clients on both sites, you can see that a client is served by the local servers while a local server is available.</p>
 </li>
 </ol>
-<h3 id="exposing-services-on-the-service-network-from-a-namespace">Exposing services on the service network from a namespace</h3>
+<h2 id="exposing-services-on-the-service-network-from-a-namespace">Exposing services on the service network from a namespace</h2>
 <p>After creating a service network, exposed services can communicate across that network.</p>
 <p>The <code>skupper</code> CLI has two options for exposing services that already exist in a namespace:</p>
 <ul>
@@ -259,7 +259,7 @@ <h3 id="exposing-services-on-the-service-network-from-a-namespace">Exposing serv
 <li><code>service create</code> and <code>service bind</code> is a more flexible method of exposing services, for example, if you have multiple services for a deployment.
 See <a href="#exposing-complex-services-on-the-service-network">Exposing complex services on the service network</a> for instructions.</li>
 </ul>
-<h4 id="exposing-simple-services-on-the-service-network">Exposing simple services on the service network</h4>
+<h3 id="exposing-simple-services-on-the-service-network">Exposing simple services on the service network</h3>
 <p>This section describes how services can be enabled for a service network for simple use cases.</p>
 <ol>
 <li><p>Create a deployment, some pods, or a service in one of your sites, for example:</p>
@@ -290,7 +290,7 @@ <h4 id="exposing-simple-services-on-the-service-network">Exposing simple service
 </ol>
 <p><strong>📌 NOTE</strong><br />
 If you do not specify ports, <code>skupper</code> uses the <code>containerPort</code> value of the deployment.</p>
-<h4 id="exposing-complex-services-on-the-service-network">Exposing complex services on the service network</h4>
+<h3 id="exposing-complex-services-on-the-service-network">Exposing complex services on the service network</h3>
 <p>This section describes how services can be enabled for a service network for more complex use cases.</p>
 <ol>
 <li><p>Create a deployment, some pods, or a service in one of your sites, for example:</p>
@@ -324,7 +324,7 @@ <h4 id="exposing-complex-services-on-the-service-network">Exposing complex servi
 </code></pre>
 </li>
 </ol>
-<h4 id="exposing-services-from-a-different-namespace-to-the-service-network">Exposing services from a different namespace to the service network</h4>
+<h3 id="exposing-services-from-a-different-namespace-to-the-service-network">Exposing services from a different namespace to the service network</h3>
 <p>This section shows how to expose a service from a namespace where Skupper is not deployed.</p>
 <p>Skupper allows you expose Kubernetes services from other namespaces for any site.
 However, if you want to expose workloads, for example deployments, you must create a site as described in this section.</p>
@@ -363,7 +363,7 @@ <h4 id="exposing-services-from-a-different-namespace-to-the-service-network">Exp
 </code></pre>
 </li>
 </ol>
-<h3 id="exposing-services-on-the-service-network-from-a-local-machine">Exposing services on the service network from a local machine</h3>
+<h2 id="exposing-services-on-the-service-network-from-a-local-machine">Exposing services on the service network from a local machine</h2>
 <p>After creating a service network, you can expose services from a local machine on the service network.</p>
 <p>For example, if you run a database on a server in your data center, you can deploy a front end in a cluster that can access the data as if the database was running in the cluster.</p>
 <dl><dt><strong>📌 NOTE</strong></dt><dd>
@@ -373,7 +373,7 @@ <h3 id="exposing-services-on-the-service-network-from-a-local-machine">Exposing
 See <a href="../cli/podman.html">Using Skupper Podman</a> for information about using the Skupper CLI to create Podman sites.</p>
 </dd></dl>
 
-<h4 id="exposing-simple-local-services-to-the-service-network">Exposing simple local services to the service network</h4>
+<h3 id="exposing-simple-local-services-to-the-service-network">Exposing simple local services to the service network</h3>
 <p>This section shows how to expose a single service running locally on a service network.</p>
 <ul>
 <li>A service network. Only one site is required.</li>
@@ -412,7 +412,7 @@ <h4 id="exposing-simple-local-services-to-the-service-network">Exposing simple l
 <p>The URL field shows the underlying communication and can be ignored.</p>
 </li>
 </ol>
-<h4 id="working-with-complex-local-services-on-the-service-network">Working with complex local services on the service network</h4>
+<h3 id="working-with-complex-local-services-on-the-service-network">Working with complex local services on the service network</h3>
 <p>This section shows more advanced usage of skupper gateway.</p>
 <ol>
 <li><p>Create a Skupper gateway:</p>
@@ -471,7 +471,7 @@ <h4 id="working-with-complex-local-services-on-the-service-network">Working with
 </ul>
 </li>
 </ol>
-<h4 id="creating-a-gateway-and-applying-it-on-a-different-machine">Creating a gateway and applying it on a different machine</h4>
+<h3 id="creating-a-gateway-and-applying-it-on-a-different-machine">Creating a gateway and applying it on a different machine</h3>
 <p>If you have access to a cluster from one machine but want to create a gateway to the service network from a different machine, you can create the gateway definition bundle on the first machine and later apply that definition bundle on a second machine as described in this procedure.
 For example, if you want to expose a local database service to the service network, but you never want to access the cluster from the database server, you can use this procedure to create the definition bundle and apply it on the database server.</p>
 <ol>
@@ -569,7 +569,7 @@ <h4 id="creating-a-gateway-and-applying-it-on-a-different-machine">Creating a ga
 </ol>
 <p><strong>📌 NOTE</strong><br />
 If you need to change the gateway definition, for example to change port, you need to remove the existing gateway and repeat this procedure from the start to redefine the gateway.</p>
-<h4 id="gateway-yaml-reference">Gateway YAML reference</h4>
+<h3 id="gateway-yaml-reference">Gateway YAML reference</h3>
 <p>The <a href="#creating-a-gateway-and-applying-it-on-a-different-machine">Creating a gateway and applying it on a different machine</a> describes how to create a gateway to apply on a separate machine using a gateway definition YAML file.</p>
 <p>The following are valid entries in a gateway definition YAML file.</p>
 <ul>
@@ -626,7 +626,7 @@ <h4 id="gateway-yaml-reference">Gateway YAML reference</h4>
 <li><strong>qdr-listeners.port</strong><br />
 Port for skupper router, typically <code>5672</code>.</li>
 </ul>
-<h4 id="exploring-a-service-network">Exploring a service network</h4>
+<h2 id="exploring-a-service-network">Exploring a service network</h2>
 <p>Skupper includes a command to allow you report all the sites and the services available on a service network.</p>
 <ul>
 <li>A service network with more than one site</li>
@@ -676,11 +676,11 @@ <h4 id="exploring-a-service-network">Exploring a service network</h4>
 </ol>
 </li>
 </ol>
-<h5 id="securing-a-service-network">Securing a service network</h5>
+<h2 id="securing-a-service-network">Securing a service network</h2>
 <p>Skupper provides default, built-in security that scales across clusters and clouds.
 This section describes additional security you can configure.</p>
 <p>See <a href="../policy/index.html">Securing a service network using policies</a> for information about creating granular policies for each cluster.</p>
-<h6 id="restricting-access-to-services-using-a-kubernetes-network-policy">Restricting access to services using a Kubernetes network policy</h6>
+<h3 id="restricting-access-to-services-using-a-kubernetes-network-policy">Restricting access to services using a Kubernetes network policy</h3>
 <p>By default, if you expose a service on the service network, that service is also accessible from other namespaces in the cluster.
 You can avoid this situation when creating a site using the <code>--create-network-policy</code> option.</p>
 <ol>
@@ -697,7 +697,7 @@ <h6 id="restricting-access-to-services-using-a-kubernetes-network-policy">Restri
 </li>
 </ol>
 <p>You can now expose services on the service network and those services are not accessible from other namespaces in the cluster.</p>
-<h6 id="applying-tls-to-tcp-or-http2-traffic-on-the-service-network">Applying TLS to TCP or HTTP2 traffic on the service network</h6>
+<h3 id="applying-tls-to-tcp-or-http2-traffic-on-the-service-network">Applying TLS to TCP or HTTP2 traffic on the service network</h3>
 <p>By default, the traffic between sites is encrypted, however the traffic between the service pod and the router pod is not encrypted.
 For services exposed as TCP or HTTP2, the traffic between the pod and the router pod can be encrypted using TLS.</p>
 <ul>
@@ -758,7 +758,7 @@ <h6 id="applying-tls-to-tcp-or-http2-traffic-on-the-service-network">Applying TL
 <li><p>Test calling the service from a TLS enabled frontend.</p>
 </li>
 </ol>
-<h6 id="supported-standards-and-protocols">Supported standards and protocols</h6>
+<h2 id="supported-standards-and-protocols">Supported standards and protocols</h2>
 <p>Skupper supports the following protocols for your service network:</p>
 <ul>
 <li>TCP - default</li>
@@ -784,7 +784,7 @@ <h6 id="supported-standards-and-protocols">Supported standards and protocols</h6
 <p>TCP is implemented as a single streamed message, whereas HTTP1 and HTTP2 are implemented as request/response message routing.</p>
 </li>
 </ul>
-<p><a name="cli-global-options"></a>======= CLI options</p>
+<h2 id="cli-options">CLI options</h2>
 <p>For a full list of options, see the <a href="../kubernetes-reference/index.html">Skupper Kubernetes CLI reference</a> and <a href="../podman-reference/index.html">Skupper Podman CLI reference</a> documentation.</p>
 <dl><dt><strong>⚠️ WARNING</strong></dt><dd>
 
diff --git a/docs/docs/cli/native-security-options.html b/docs/docs/cli/native-security-options.html
index aab6fb53..4a2e47cc 100644
--- a/docs/docs/cli/native-security-options.html
+++ b/docs/docs/cli/native-security-options.html
@@ -1,7 +1,7 @@
 <!DOCTYPE html>
 <html xmlns="http://www.w3.org/1999/xhtml">
   <head>
-    <title>Skupper - Securing a service network</title>
+    <title>Skupper - #Securing a service network</title>
     <meta name="description" content="Multicluster communication for Kubernetes.  Skupper is a layer 7 service interconnect.  It enables secure communication across Kubernetes clusters with no VPNs or special firewall rules."/>
     <meta name="viewport" content="width=device-width, initial-scale=1.0"/>
     <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Lato:300,300italic,400,400italic,700,700italic|Roboto+Mono:400,400italic|Alegreya+Sans:300,300italic,400,400italic,500,500italic,700,700italic;display=optional"/>
@@ -58,7 +58,7 @@
       </div>
     </div>
   </nav>
-  <nav id="-path-nav"><div><a href="/docs/index.html">Documentation</a> <span class="path-separator">&#8250;</span> <a href="/docs/cli/index.html">Using the Skupper CLI</a> <span class="path-separator">&#8250;</span> <a href="/docs/cli/native-security-options.html">Securing a service network</a></div></nav>
+  <nav id="-path-nav"><div><a href="/docs/index.html">Documentation</a> <span class="path-separator">&#8250;</span> <a href="/docs/cli/index.html">Using the Skupper CLI</a> <span class="path-separator">&#8250;</span> <a href="/docs/cli/native-security-options.html">#Securing a service network</a></div></nav>
   <nav id="-site-menu-layer" style="display: none;">
     <div>
       <a href="/index.html">Home</a>
@@ -75,11 +75,11 @@
   <div>
     <main>
 
-<h1 id="securing-a-service-network">Securing a service network</h1>
+<h2 id="securing-a-service-network">Securing a service network</h2>
 <p>Skupper provides default, built-in security that scales across clusters and clouds.
 This section describes additional security you can configure.</p>
 <p>See <a href="../policy/index.html">Securing a service network using policies</a> for information about creating granular policies for each cluster.</p>
-<h2 id="restricting-access-to-services-using-a-kubernetes-network-policy">Restricting access to services using a Kubernetes network policy</h2>
+<h3 id="restricting-access-to-services-using-a-kubernetes-network-policy">Restricting access to services using a Kubernetes network policy</h3>
 <p>By default, if you expose a service on the service network, that service is also accessible from other namespaces in the cluster.
 You can avoid this situation when creating a site using the <code>--create-network-policy</code> option.</p>
 <ol>
@@ -96,7 +96,7 @@ <h2 id="restricting-access-to-services-using-a-kubernetes-network-policy">Restri
 </li>
 </ol>
 <p>You can now expose services on the service network and those services are not accessible from other namespaces in the cluster.</p>
-<h2 id="applying-tls-to-tcp-or-http2-traffic-on-the-service-network">Applying TLS to TCP or HTTP2 traffic on the service network</h2>
+<h3 id="applying-tls-to-tcp-or-http2-traffic-on-the-service-network">Applying TLS to TCP or HTTP2 traffic on the service network</h3>
 <p>By default, the traffic between sites is encrypted, however the traffic between the service pod and the router pod is not encrypted.
 For services exposed as TCP or HTTP2, the traffic between the pod and the router pod can be encrypted using TLS.</p>
 <ul>
diff --git a/docs/docs/cli/podman.html b/docs/docs/cli/podman.html
index 79837e11..82adcd92 100644
--- a/docs/docs/cli/podman.html
+++ b/docs/docs/cli/podman.html
@@ -246,7 +246,7 @@ <h2 id="specifying-link-cost">Specifying link cost</h2>
 For example, in a two site network linked with a high cost with servers and clients on both sites, you can see that a client is served by the local servers while a local server is available.</p>
 </li>
 </ol>
-<h3 id="exposing-services-on-the-service-network-from-a-linux-host">Exposing services on the service network from a Linux host</h3>
+<h2 id="exposing-services-on-the-service-network-from-a-linux-host">Exposing services on the service network from a Linux host</h2>
 <p>After creating a service network, exposed services can communicate across that network.</p>
 <p>The general flow for working with services is the same for Kubernetes and Podman sites.</p>
 <p>The <code>skupper</code> CLI has two options for exposing services that already exist on a host:</p>
@@ -256,7 +256,7 @@ <h3 id="exposing-services-on-the-service-network-from-a-linux-host">Exposing ser
 <li><code>service create</code> and <code>service bind</code> is a more flexible method of exposing services, for example, if you have multiple services for a host.
 See <a href="#exposing-complex-services-on-the-service-network">Exposing complex services on the service network</a> for instructions.</li>
 </ul>
-<h4 id="exposing-simple-services-on-the-service-network">Exposing simple services on the service network</h4>
+<h3 id="exposing-simple-services-on-the-service-network">Exposing simple services on the service network</h3>
 <p>This section describes how services can be enabled for a service network for simple use cases.</p>
 <ul>
 <li>A Skupper Podman site</li>
@@ -292,7 +292,7 @@ <h4 id="exposing-simple-services-on-the-service-network">Exposing simple service
 </code></pre>
 </li>
 </ol>
-<h4 id="exposing-complex-services-on-the-service-network">Exposing complex services on the service network</h4>
+<h3 id="exposing-complex-services-on-the-service-network">Exposing complex services on the service network</h3>
 <p>This section describes how services can be enabled for a service network for more complex use cases.</p>
 <ul>
 <li>A Skupper Podman site</li>
@@ -329,7 +329,7 @@ <h4 id="exposing-complex-services-on-the-service-network">Exposing complex servi
 </code></pre>
 </li>
 </ol>
-<h4 id="consuming-simple-services-from-the-service-network">Consuming simple services from the service network</h4>
+<h3 id="consuming-simple-services-from-the-service-network">Consuming simple services from the service network</h3>
 <p>Services exposed on Podman sites are not automatically available to other sites.
 This is the equivalent to Kubernetes sites created using <code>skupper init --enable-service-sync false</code>.</p>
 <ul>
@@ -344,7 +344,7 @@ <h4 id="consuming-simple-services-from-the-service-network">Consuming simple ser
 </code></pre>
 </li>
 </ol>
-<h3 id="deleting-a-podman-site">Deleting a Podman site</h3>
+<h2 id="deleting-a-podman-site">Deleting a Podman site</h2>
 <p>When you no longer want the Linux host to be part of the service network, you can delete the site.</p>
 <dl><dt><strong>📌 NOTE</strong></dt><dd>
 
diff --git a/input/docs/cli/index.md b/input/docs/cli/index.md
index 2c4ce700..d26e706d 100644
--- a/input/docs/cli/index.md
+++ b/input/docs/cli/index.md
@@ -214,7 +214,7 @@ After this threshold of open connections is reached, new connections are spread
    If there are multiple clients on different sites, filter the view to each client to determine the effect of cost on traffic.
    For example, in a two site network linked with a high cost with servers and clients on both sites, you can see that a client is served by the local servers while a local server is available.
 
-### Exposing services on the service network from a namespace
+## Exposing services on the service network from a namespace
 
 After creating a service network, exposed services can communicate across that network.
 
@@ -225,7 +225,7 @@ See [Exposing simple services on the service network](#exposing-simple-services-
 * `service create` and `service bind` is a more flexible method of exposing services, for example, if you have multiple services for a deployment.
 See [Exposing complex services on the service network](#exposing-complex-services-on-the-service-network) for instructions.
 
-#### Exposing simple services on the service network
+### Exposing simple services on the service network
 This section describes how services can be enabled for a service network for simple use cases.
 
 1. Create a deployment, some pods, or a service in one of your sites, for example:
@@ -262,7 +262,7 @@ This section describes how services can be enabled for a service network for sim
 **📌 NOTE**\
 If you do not specify ports, `skupper` uses the `containerPort` value of the deployment.
 
-#### Exposing complex services on the service network
+### Exposing complex services on the service network
 
 This section describes how services can be enabled for a service network for more complex use cases.
 
@@ -305,7 +305,7 @@ This section describes how services can be enabled for a service network for mor
    $ skupper service bind hello-world-backend deployment hello-world-backend
    ```
 
-#### Exposing services from a different namespace to the service network
+### Exposing services from a different namespace to the service network
 
 This section shows how to expose a service from a namespace where Skupper is not deployed.
 
@@ -353,7 +353,7 @@ However, if you want to expose workloads, for example deployments, you must crea
    $ skupper expose deployment/backend --port 8080 --target-namespace east-backend
    ```
 
-### Exposing services on the service network from a local machine
+## Exposing services on the service network from a local machine
 
 After creating a service network, you can expose services from a local machine on the service network.
 
@@ -366,7 +366,7 @@ An alternative approach is to create a site on the local host and link to the cl
 See [Using Skupper Podman](../cli/podman.html) for information about using the Skupper CLI to create Podman sites.
 </dd></dl>
 
-#### Exposing simple local services to the service network
+### Exposing simple local services to the service network
 
 This section shows how to expose a single service running locally on a service network.
 
@@ -407,7 +407,7 @@ This section shows how to expose a single service running locally on a service n
 
    The URL field shows the underlying communication and can be ignored.
 
-#### Working with complex local services on the service network
+### Working with complex local services on the service network
 
 This section shows more advanced usage of skupper gateway.
 
@@ -479,7 +479,7 @@ This section shows more advanced usage of skupper gateway.
    * `<service>` is the name of an existing service on the service network.
    * `<port>` is the port on the local machine that you want to use.
 
-#### Creating a gateway and applying it on a different machine
+### Creating a gateway and applying it on a different machine
 
 If you have access to a cluster from one machine but want to create a gateway to the service network from a different machine, you can create the gateway definition bundle on the first machine and later apply that definition bundle on a second machine as described in this procedure.
 For example, if you want to expose a local database service to the service network, but you never want to access the cluster from the database server, you can use this procedure to create the definition bundle and apply it on the database server.
@@ -593,7 +593,7 @@ For example, if you want to expose a local database service to the service netwo
 **📌 NOTE**\
 If you need to change the gateway definition, for example to change port, you need to remove the existing gateway and repeat this procedure from the start to redefine the gateway.
 
-#### Gateway YAML reference
+### Gateway YAML reference
 
 The [Creating a gateway and applying it on a different machine](#creating-a-gateway-and-applying-it-on-a-different-machine) describes how to create a gateway to apply on a separate machine using a gateway definition YAML file.
 
@@ -652,7 +652,7 @@ Hostname for skupper router, typically `localhost`.
 * **qdr-listeners.port**\
 Port for skupper router, typically `5672`.
 
-#### Exploring a service network
+## Exploring a service network
 
 Skupper includes a command to allow you report all the sites and the services available on a service network.
 
@@ -704,14 +704,14 @@ Skupper includes a command to allow you report all the sites and the services av
    5. The sites that the remote site is linked to.
    6. The unique identifier of a remote podman site. Podman sites do not have an associated context.
 
-##### Securing a service network
+## Securing a service network
 
 Skupper provides default, built-in security that scales across clusters and clouds.
 This section describes additional security you can configure.
 
 See [Securing a service network using policies](../policy/index.html) for information about creating granular policies for each cluster.
 
-###### Restricting access to services using a Kubernetes network policy
+### Restricting access to services using a Kubernetes network policy
 
 By default, if you expose a service on the service network, that service is also accessible from other namespaces in the cluster.
 You can avoid this situation when creating a site using the `--create-network-policy` option.
@@ -733,7 +733,7 @@ You can avoid this situation when creating a site using the `--create-network-po
 
 You can now expose services on the service network and those services are not accessible from other namespaces in the cluster.
 
-###### Applying TLS to TCP or HTTP2 traffic on the service network
+### Applying TLS to TCP or HTTP2 traffic on the service network
 
 By default, the traffic between sites is encrypted, however the traffic between the service pod and the router pod is not encrypted.
 For services exposed as TCP or HTTP2, the traffic between the pod and the router pod can be encrypted using TLS.
@@ -798,7 +798,7 @@ For services exposed as TCP or HTTP2, the traffic between the pod and the router
    ```
 5. Test calling the service from a TLS enabled frontend.
 
-###### Supported standards and protocols
+## Supported standards and protocols
 
 Skupper supports the following protocols for your service network:
 
@@ -826,7 +826,7 @@ When choosing which protocol to specify, note the following:
 
   TCP is implemented as a single streamed message, whereas HTTP1 and HTTP2 are implemented as request/response message routing.
 
-<a name="cli-global-options"></a>======= CLI options
+## CLI options
 
 For a full list of options, see the [Skupper Kubernetes CLI reference](../kubernetes-reference/index.html) and [Skupper Podman CLI reference](../podman-reference/index.html) documentation.
 
diff --git a/input/docs/cli/native-security-options.md b/input/docs/cli/native-security-options.md
index b3ab4ff0..d9ad1f4c 100644
--- a/input/docs/cli/native-security-options.md
+++ b/input/docs/cli/native-security-options.md
@@ -1,14 +1,14 @@
 ---
-title: Securing a service network
+title: #Securing a service network
 ---
-# Securing a service network
+## Securing a service network
 
 Skupper provides default, built-in security that scales across clusters and clouds.
 This section describes additional security you can configure.
 
 See [Securing a service network using policies](../policy/index.html) for information about creating granular policies for each cluster.
 
-## Restricting access to services using a Kubernetes network policy
+### Restricting access to services using a Kubernetes network policy
 
 By default, if you expose a service on the service network, that service is also accessible from other namespaces in the cluster.
 You can avoid this situation when creating a site using the `--create-network-policy` option.
@@ -30,7 +30,7 @@ You can avoid this situation when creating a site using the `--create-network-po
 
 You can now expose services on the service network and those services are not accessible from other namespaces in the cluster.
 
-## Applying TLS to TCP or HTTP2 traffic on the service network
+### Applying TLS to TCP or HTTP2 traffic on the service network
 
 By default, the traffic between sites is encrypted, however the traffic between the service pod and the router pod is not encrypted.
 For services exposed as TCP or HTTP2, the traffic between the pod and the router pod can be encrypted using TLS.
diff --git a/input/docs/cli/podman.md b/input/docs/cli/podman.md
index 41a1d318..9f200fda 100644
--- a/input/docs/cli/podman.md
+++ b/input/docs/cli/podman.md
@@ -212,7 +212,7 @@ After this threshold of open connections is reached, new connections are spread
    If there are multiple clients on different sites, filter the view to each client to determine the effect of cost on traffic.
    For example, in a two site network linked with a high cost with servers and clients on both sites, you can see that a client is served by the local servers while a local server is available.
 
-### Exposing services on the service network from a Linux host
+## Exposing services on the service network from a Linux host
 
 After creating a service network, exposed services can communicate across that network.
 
@@ -225,7 +225,7 @@ See [Exposing simple services on the service network](#exposing-simple-services-
 * `service create` and `service bind` is a more flexible method of exposing services, for example, if you have multiple services for a host.
 See [Exposing complex services on the service network](#exposing-complex-services-on-the-service-network) for instructions.
 
-#### Exposing simple services on the service network
+### Exposing simple services on the service network
 This section describes how services can be enabled for a service network for simple use cases.
 
 * A Skupper Podman site
@@ -266,7 +266,7 @@ This section describes how services can be enabled for a service network for sim
    $ skupper service create backend 8080
    ```
 
-#### Exposing complex services on the service network
+### Exposing complex services on the service network
 
 This section describes how services can be enabled for a service network for more complex use cases.
 
@@ -311,7 +311,7 @@ This section describes how services can be enabled for a service network for mor
    $ skupper service bind hello-world-backend host hello-world-backend
    ```
 
-#### Consuming simple services from the service network
+### Consuming simple services from the service network
 
 Services exposed on Podman sites are not automatically available to other sites.
 This is the equivalent to Kubernetes sites created using `skupper init --enable-service-sync false`.
@@ -326,7 +326,7 @@ This is the equivalent to Kubernetes sites created using `skupper init --enable-
    $ skupper service create <service-name> <port number>
    ```
 
-### Deleting a Podman site
+## Deleting a Podman site
 
 When you no longer want the Linux host to be part of the service network, you can delete the site.
 
diff --git a/subrepos/skupper-docs/cli/gateway.adoc b/subrepos/skupper-docs/cli/gateway.adoc
index 0a978cf5..2a11a6c5 100644
--- a/subrepos/skupper-docs/cli/gateway.adoc
+++ b/subrepos/skupper-docs/cli/gateway.adoc
@@ -1,6 +1,6 @@
 // Type: concept
 [id="exposing-services-local"] 
-= Exposing services on the {service-network} from a local machine
+== Exposing services on the {service-network} from a local machine
 
 After creating a {service-network}, you can expose services from a local machine on the {service-network}.
 
@@ -15,7 +15,7 @@ See link:{podman-link} for information about using the Skupper CLI to create Pod
 
 // Type: procedure
 [id="exposing-service-gateway"] 
-== Exposing simple local services to the {service-network}
+=== Exposing simple local services to the {service-network}
 
 This section shows how to expose a single service running locally on a {service-network}.
 
@@ -73,7 +73,7 @@ The URL field shows the underlying communication and can be ignored.
 
 // Type: procedure
 [id="exposing-services-gateway"] 
-== Working with complex local services on the {service-network}
+=== Working with complex local services on the {service-network}
 
 
 This section shows more advanced usage of skupper gateway.
@@ -173,7 +173,7 @@ where
 
 // Type: procedure
 [id="exporting-gateway"] 
-== Creating a gateway and applying it on a different machine
+=== Creating a gateway and applying it on a different machine
 
 If you have access to a cluster from one machine but want to create a gateway to the {service-network} from a different machine, you can create the gateway definition bundle on the first machine and later apply that definition bundle on a second machine as described in this procedure.
 For example, if you want to expose a local database service to the {service-network}, but you never want to access the cluster from the database server, you can use this procedure to create the definition bundle and apply it on the database server.
@@ -325,7 +325,7 @@ NOTE: If you need to change the gateway definition, for example to change port,
 
 // Type: procedure
 [id="gateway-reference"] 
-== Gateway YAML reference
+=== Gateway YAML reference
 
 The xref:exporting-gateway[] describes how to create a gateway to apply on a separate machine using a gateway definition YAML file.
 
diff --git a/subrepos/skupper-docs/cli/index.adoc b/subrepos/skupper-docs/cli/index.adoc
index 0ae61e3e..53aa99d9 100644
--- a/subrepos/skupper-docs/cli/index.adoc
+++ b/subrepos/skupper-docs/cli/index.adoc
@@ -197,7 +197,7 @@ $ skupper link delete <link-name>
 where `<link-name>` is the name of the link specified during creation.
 -- 
 
-include::link-cost.adoc[leveloffset=+1]
+include::link-cost.adoc[leveloffset=0]
 
 // Type: concept
 [id="kubernetes_exposing-services-ns"] 
@@ -391,13 +391,13 @@ $ skupper expose deployment/backend --port 8080 --target-namespace east-backend
 ----
 --
 
-include::./gateway.adoc[leveloffset=+1]
+include::./gateway.adoc[leveloffset=0]
 
-include::./network-status.adoc[leveloffset=+1]
+include::./network-status.adoc[leveloffset=0]
 
-include::./native-security-options.adoc[leveloffset=+1]
+include::./native-security-options.adoc[leveloffset=0]
 
-include::./protocols.adoc[leveloffset=+1]
+include::./protocols.adoc[leveloffset=0]
 
 // Type: reference
 [id="cli-global-options"] 
diff --git a/subrepos/skupper-docs/cli/link-cost.adoc b/subrepos/skupper-docs/cli/link-cost.adoc
index 24ffe54d..c1c95d92 100644
--- a/subrepos/skupper-docs/cli/link-cost.adoc
+++ b/subrepos/skupper-docs/cli/link-cost.adoc
@@ -1,6 +1,6 @@
 // Type: procedure
 [id="{context}_link-cost"] 
-= Specifying link cost
+== Specifying link cost
 
 When linking sites, you can assign a cost to each link to influence the traffic flow. 
 By default, link cost is set to `1` for a new link.
diff --git a/subrepos/skupper-docs/cli/native-security-options.adoc b/subrepos/skupper-docs/cli/native-security-options.adoc
index a91e5916..de68b77a 100644
--- a/subrepos/skupper-docs/cli/native-security-options.adoc
+++ b/subrepos/skupper-docs/cli/native-security-options.adoc
@@ -1,7 +1,7 @@
 include::../partials/attributes.adoc[]
 // Type: assembly
 [id="built-in-security-options"] 
-= Securing a service network
+== Securing a service network
 
 Skupper provides default, built-in security that scales across clusters and clouds.
 This section describes additional security you can configure.
@@ -10,7 +10,7 @@ See link:{policy-link} for information about creating granular policies for each
 
 // Type: procedure
 [id="network-policy"] 
-== Restricting access to services using a Kubernetes network policy
+=== Restricting access to services using a Kubernetes network policy
 
 By default, if you expose a service on the {service-network}, that service is also accessible from other namespaces in the cluster.
 You can avoid this situation when creating a site using the `--create-network-policy` option.
@@ -42,7 +42,7 @@ You can now expose services on the {service-network} and those services are not
 
 // Type: procedure
 [id="tls"] 
-== Applying TLS to TCP or HTTP2 traffic on the {service-network}
+=== Applying TLS to TCP or HTTP2 traffic on the {service-network}
 
 By default, the traffic between sites is encrypted, however the traffic between the service pod and the router pod is not encrypted.
 For services exposed as TCP or HTTP2, the traffic between the pod and the router pod can be encrypted using TLS.
diff --git a/subrepos/skupper-docs/cli/network-status.adoc b/subrepos/skupper-docs/cli/network-status.adoc
index 192601b7..56fc3dce 100644
--- a/subrepos/skupper-docs/cli/network-status.adoc
+++ b/subrepos/skupper-docs/cli/network-status.adoc
@@ -1,6 +1,6 @@
 // Type: procedure
 [id='network-service']
-= Exploring a {service-network}
+== Exploring a {service-network}
 
 Skupper includes a command to allow you report all the sites and the services available on a {service-network}.
 
diff --git a/subrepos/skupper-docs/cli/podman.adoc b/subrepos/skupper-docs/cli/podman.adoc
index d0e46761..a1e899ab 100644
--- a/subrepos/skupper-docs/cli/podman.adoc
+++ b/subrepos/skupper-docs/cli/podman.adoc
@@ -189,7 +189,7 @@ After you have linked to a network, you can check the link status:
 $ skupper link status
 ----
 
-include::link-cost.adoc[leveloffset=+1]
+include::link-cost.adoc[leveloffset=0]
 
 // Type: concept
 [id="podman_exposing-services-ns"] 
diff --git a/subrepos/skupper-docs/cli/protocols.adoc b/subrepos/skupper-docs/cli/protocols.adoc
index c12c9186..4a314d30 100644
--- a/subrepos/skupper-docs/cli/protocols.adoc
+++ b/subrepos/skupper-docs/cli/protocols.adoc
@@ -1,6 +1,6 @@
 // Type: reference
 [id='protocols']
-= Supported standards and protocols
+== Supported standards and protocols
 
 Skupper supports the following protocols for your {service-network}: