Documentation corrections (#7761)

Author: achamayou

doc/operations/cli.rst

@@ -21,7 +21,7 @@ Each CCF executable exposes the following command-line interface (CLI) options:
         --log-level ENUM:value in {debug->1,fail->3,fatal->4,info->2,trace->0} OR {1,3,4,2,0}
                                     Logging level for the node (security critical)
 
-Note that the ``--enclave-log-level`` option is security critical.
-They must be passed on the command line rather than in a configuration file, so that their values are captured in an attestation even if the configuration file itself is not attested, for example because it is mounted from an external, un-attested, filesystem.
+Note that the ``--log-level`` option is security critical.
+It must be passed on the command line rather than in a configuration file, so that its value is captured in an attestation even if the configuration file itself is not attested, for example because it is mounted from an external, un-attested, filesystem.
 
 The ``--config-timeout`` option specifies how long to wait for the configuration file to be available before giving up. This is useful when running CCF in a container, where the configuration file may not be immediately available.

doc/operations/configuration.rst

@@ -29,7 +29,7 @@ The `enabled_operator_features` configuration field allows enabling or disabling
 Currently supported features are:
 
 1. 'SnapshotRead': gates access to endpoints used to fetch snapshots directly from nodes (:http:GET:`/node/snapshot`, :http:HEAD:`/node/snapshot`, :http:GET:`/node/snapshot/{snapshot_name}` and :http:HEAD:`/node/snapshot/{snapshot_name}`).
-2. 'LedgerChunkRead': gates access to endpoints used to retrieve ledger chunks, to be added in a future release.
+2. 'LedgerChunkRead': gates access to endpoints used to retrieve ledger chunks (:http:GET:`/node/ledger-chunk`, :http:HEAD:`/node/ledger-chunk`, :http:GET:`/node/ledger-chunk/{chunk_name}` and :http:HEAD:`/node/ledger-chunk/{chunk_name}`).
 
 Since these operations may require disk IO and produce large responses, these features should not be enabled on interfaces with public access, and instead restricted to interfaces with local connectivity for node-to-node and operator access.
 

doc/operations/ledger_snapshot.rst

@@ -47,10 +47,10 @@ The listing below is an example of what a ledger directory may look like:
 Download Endpoints
 ~~~~~~~~~~~~~~~~~~
 
-In order to faciliate long term backup of the ledger files (also called chunks), nodes can enable HTTP endpoints that allow a client to download committed ledger files.
-The `LedgerChunkDownload` feature must be added to `enabled_operator_features` on the relevant `rpc_interfaces` entries in the node configuration.
+In order to facilitate long term backup of the ledger files (also called chunks), nodes can enable HTTP endpoints that allow a client to download committed ledger files.
+The `LedgerChunkRead` feature must be added to `enabled_operator_features` on the relevant `rpc_interfaces` entries in the node configuration.
 
-1. :http:GET:`/node/ledger-chunk` and :http:HEAD:`/node/ledger-chunk`, both taking a `seqno` query parameter.
+1. :http:GET:`/node/ledger-chunk` and :http:HEAD:`/node/ledger-chunk`, both taking a `since` query parameter.
 
 These endpoints can be used by a client to download the next ledger chunk including a given sequence number `<seqno>`.
 They redirect to the appropriate chunk if it exists, using the endpoints described below, or return a `404 Not Found` response if no such chunk is available.

doc/operations/resource_usage.rst

@@ -11,8 +11,7 @@ It is possible to add additional worker threads inside the enclave via the :ref:
 Memory
 ------
 
-The maximum amount of heap memory usable in the enclave is set in the configuration passed to the oesign tool (``oe_sign.conf``), when creating the enclave binary file.
-
-This amount cannot be exceeded, or modified after the fact, so it is necessary to set it in advance to the maximum amount of memory the application is ever expected to consume.
+The memory available to a CCF node process is ultimately bounded by the environment it runs in, typically the size of the virtual machine (VM) or container, and any additional OS- or container-level limits applied to the process.
+On SEV-SNP, the node process runs inside a confidential VM; the VM size chosen at deployment time sets an upper bound on the memory that can be made available to the node, subject to any further limits imposed by the guest OS or container.
 
 .. note:: If a JavaScript application is deployed, then by default the source code is pre-compiled into bytecode and stored in the Key Value store. While this reduces RPC latency it increases memory usage. The size of the bytecode cache can be queried via the ``/node/js_metrics`` RPC. See the :ref:`JavaScript Deployment <build_apps/js_app_bundle:Deployment>` section for details on enabling or disabling the cache.