diff --git a/developer/monitoring.rst b/developer/monitoring.rst
index 9fd74db..1339fec 100644
--- a/developer/monitoring.rst
+++ b/developer/monitoring.rst
@@ -76,12 +76,13 @@ or Slack channel).
    capability to Aether OnRamp (so it is available to anyone that
    wants to operate Aether) is pending.
 
-To add an alert for a component, create a
-`PrometheusRule <https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/user-guides/alerting.md>`_
-custom resource, for example in the Helm chart that deploys the component.  This resource describes one or
-more `rules <https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/>`_ using Prometheus expressions;
-if the expression is true for the time indicated, then the alert is raised. Once the PrometheusRule
-resource is instantiated, the cluster's Prometheus will pick up the rule and start evaluating it.
+To add an alert for a component, create a *PrometheusRule* custom
+resource, for example in the Helm chart that deploys the component.
+This resource describes one or more rules using Prometheus
+expressions; if the expression is true for the time indicated, then
+the alert is raised. Once the PrometheusRule resource is instantiated,
+the cluster's Prometheus will pick up the rule and start evaluating
+it.
 
 The Alertmanager is configured to send alerts with *critical* or *warning* severity to e-mail and Slack channels
 monitored by Aether OPs staff.  If it is desirable to route a specific alert to a different receiver
diff --git a/onramp/blueprints.rst b/onramp/blueprints.rst
index 8b97a65..2126bf4 100644
--- a/onramp/blueprints.rst
+++ b/onramp/blueprints.rst
@@ -34,11 +34,12 @@ Ansible components:
   pipelines are defined by Groovy scripts, and can be found in the
   ``aether-jenkins`` repo.
 
-The goal of establishing a well-defined procedure for adding new
-blueprints to OnRamp is to encourage the community to contribute (and
+The above list also establishes the requirements for adding new
+blueprints to OnRamp. The community is to encourage to contribute (and
 maintain) new Aether configurations and deployment scenarios.\ [#]_
 The rest of this section documents community-contributed blueprints
-to-date.
+to-date; the concluding subsection gives a set of guidelines for
+creating new blueprints.
 
 .. [#] Not all possible configurations of Aether require a
        blueprint. There are other ways to add variability, for
@@ -72,7 +73,7 @@ The Multi-UPF blueprint includes the following:
   :doc:`Emulated RAN </onramp/gnbsim>` section.  Minimally,
   SD-Core runs on one server and gNBsim runs on a second server.
   (The Quick Start deployment, with both SD-Core and gNBsim running
-  in the same server, also works.)
+  in the same server, may also work, but is not actively maintained.)
 
 * New make targets, ``5gc-upf-install`` and ``5gc-upf-uninstall``, to
   be executed after the standard SD-Core installation. The blueprint
@@ -186,7 +187,7 @@ the emulation, type:
 
 .. code-block::
 
-   $ make gnbsim-simulator-run
+   $ make gnbsim-run
 
 To verify that both UPFs were functional, you will need to look at the
 ``summary.log`` file from both instances of gNBsim:
diff --git a/onramp/ref.rst b/onramp/ref.rst
index 895184d..2b9a7bd 100644
--- a/onramp/ref.rst
+++ b/onramp/ref.rst
@@ -91,7 +91,7 @@ the list is not comprehensive.
      - Description
    * - `core.ran_subnet`
      - `172.20.0.0/16`
-     - Subnet connecting Core to RAN when gNBs run in a container; set to empty string ("") when gNBs are directly connected via `core.data_iface`.
+     - Overlay subnet connecting Core to RAN when gNBs run in a container; set to empty string ("") when gNBs are directly connected via `core.data_iface`.
    * - `core.standalone`
      - `true`
      - Core to run standalone, initialized from values file; set to `false` when Core is to be initialized by ROC.
@@ -305,10 +305,10 @@ do not need to be modified for an initial deployment of a blueprint.
      - Description
    * - `172.20.0.0/16`
      - ``aether.ran_subnet``
-     - Assigned to container-based gNBs connecting to the Core. Other
-       gNB implementations connect to the Core over the subnet
-       assigned to the server's physical interface (as defined by
-       ``core.data_iface``).
+     - Assigned to container-based gNBs connecting to the Core via an
+       overlay subnet. Other gNB implementations connect to the Core
+       over the subnet assigned to the server's physical interface (as
+       defined by ``core.data_iface``).
    * - `192.168.250.0/24`
      - ``core.upf.core_subnet``
      - Assigned to `core` bridge that connects UPF(s) to the Internet.