diff --git a/.github/workflows/bazel.yml b/.github/workflows/bazel.yml
index 459bc8c..4014539 100644
--- a/.github/workflows/bazel.yml
+++ b/.github/workflows/bazel.yml
@@ -16,20 +16,7 @@ jobs:
       - uses: actions/checkout@v4
         with:
           submodules: recursive
-      - name: Mount bazel cache
-        uses: actions/cache@v4
-        with:
-          # See https://docs.bazel.build/versions/master/output_directories.html
-          path: "~/.cache/bazel"
-          # Create a new cache entry whenever Bazel files change.
-          # See https://docs.github.com/en/actions/guides/caching-dependencies-to-speed-up-workflows
-          key: bazel-${{ runner.os }}-build-${{ hashFiles('**/*.bzl', '**/*.bazel') }}
-          restore-keys: |
-            bazel-${{ runner.os }}-build-
-      - name: Install bazelisk
-        run: |
-          curl -LO "https://github.com/bazelbuild/bazelisk/releases/download/v1.19.0/$BAZEL"
-          chmod +x $BAZEL
-          sudo mv $BAZEL /usr/local/bin/bazel
+      - name: Setup Bazel
+        uses: bazelbuild/setup-bazelisk@v2
       - name: Build
         run: bazel build //...
diff --git a/certz/README.md b/certz/README.md
index a643f87..d724770 100644
--- a/certz/README.md
+++ b/certz/README.md
@@ -38,9 +38,10 @@ The normal use-case would be to:
 SSL profiles logically group a certificate (private and public keys),
 Certificate Authority chain of certificates (a.k.a. a CA trust bundle) and
 a set of Certificate Revocation Lists into a set that then can be assigned
-as a whole to a gRPC server.
+as a whole to a gRPC service.
 
-There is always at least one profile present on a target - the `system_default_profile` which is vendor provided.
+There is always at least one profile present on a target - the `system_default_profile`
+which is vendor provided.
 This profile cannot be changed or deleted.
 See the the [System default SSL profile](#system-default-ssl-profile) section below.
 
@@ -49,9 +50,9 @@ Profiles existing on a target can be discovered using the
 
 A SSL profile can be added using the `Certz.AddProfile()` RPC.
 
-When no longer a profile is needed it can be removed from the target via
-`Certz.DeleteProfile()` RPC. Note that the gNxI SSL profile cannot be
-removed.
+When a profile is no longer needed it can be removed from the target via
+`Certz.DeleteProfile()` RPC. Note that the system_default_profile SSL
+profile cannot be removed.
 
 The SSL profile ID of a gRPC server is exposed in the YANG leaf
 `ssl-profile-id` which is an augment to the
diff --git a/certz/certz.proto b/certz/certz.proto
index c6f9602..466d244 100644
--- a/certz/certz.proto
+++ b/certz/certz.proto
@@ -81,6 +81,8 @@ option go_package = "github.com/openconfig/gnsi/cert";
 // There is at least one SSL profile present on the target, the one that is used
 // by all gNxI microservices. It is created during the bootstrap phase and
 // cannot be removed.
+// SSL profiles maybe used by client, server or both services on the target
+// device.
 // Other services that require credentials _can_ use the same SSL profile as
 // the gNxI server or they can use a SSL profiles that is created using
 // the `AddProfile()` RPC. In any case, the assignment of a SSL profile to