Apply suggestions from code review

Co-authored-by: Ivan Blinkov <ivan@blinkov.ru>

ydb/docs/en/core/maintenance/manual/dynamic-config.md

@@ -8,31 +8,31 @@ Dynamic configuration allows running dynamic [nodes](../../concepts/cluster/comm
 
 This configuration is uploaded to the cluster, where it is reliably stored and delivered to each dynamic node upon startup. [Certain settings](#dynamic-kinds) are updated on the fly without restarting nodes. Using dynamic configuration, you can centrally solve the following tasks:
 
-* Change logging levels for all or specific components on the entire cluster or on the specific groups of nodes;
-* Enable experimental features (feature flags) on specific databases;
+* Change logging levels for all or specific components across the entire cluster or for specific groups of nodes.
+* Enable experimental features (feature flags) on specific databases.
 * Change actor system settings on individual nodes or groups of nodes.
 
 ## Preparing to use the dynamic configuration {#preparation}
 
 The following tasks should be performed before using the dynamic configuration in the cluster:
 
-1. Enable the [database node authorization](../../reference/configuration/node_authorization.md) upon their registration in the cluster.
+1. Enable [database node authorization](../../reference/configuration/node_authorization.md) during their registration in the cluster.
 
-1. In case the [CMS-based configuration management](cms.md) has been used in the cluster, offload the current CMS settings in the YAML format using the following command:
+1. Export the current settings from the [CMS](../../concepts/glossary.md#cms) in YAML format using the following command if [CMS-based configuration management](cms.md) has been used in the cluster:
 
     ```bash
     ./ydbd -s grpcs://<node1.ydb.tech>:2135 --ca-file ca.crt --token-file ydbd-token \
          admin console configs dump-yaml > dynconfig.yaml
     ```
 
-    Before running the command shown above, obtain the authentication token using command `ydb auth get-token`, as shown in the [cluster initialization procedure](../../devops/manual/initial-deployment.md#initialize-cluster).
+    Before running the command shown above, obtain the authentication token using the `ydb auth get-token` command, as detailed in the [cluster initial deployment procedure](../../devops/manual/initial-deployment.md#initialize-cluster).
 
 1. Prepare the initial dynamic configuration file:
 
-   * In case there are non-empty CMS settings exported at the previous step, adjust the YAML file with the exported CMS settings:
-      * add the `metadata` section based on the [configuration example](#example);
-      * add the `yaml_config_enabled: true` parameter to the `config` section.
-   * In case there are no previous CMS-based settings, use the [minimal configuration example](#example).
+   * If there are non-empty CMS settings exported in the previous step, adjust the YAML file with the exported CMS settings:
+      * Add the `metadata` section based on the [configuration example](#example).
+      * Add the `yaml_config_enabled: true` parameter to the `config` section.
+   * If there are no previous CMS-based settings, use the [minimal configuration example](#example).
    * For clusters using TLS encryption for [actor system interconnect](../../concepts/glossary.md#actor-system-interconnect), add the [interconnect TLS settings](../../reference/configuration/tls.md#interconnect) to the `config` section.
 
 1. Apply the dynamic configuration settings file to the cluster:
@@ -44,7 +44,7 @@ The following tasks should be performed before using the dynamic configuration i
 
 {% note info %}
 
-After turning on the dynamic configuration support on {{ ydb-short-name }} cluster, old-style configuration management through CMS will become unavailable.
+The legacy configuration management via CMS will become unavailable after enabling dynamic configuration support on the {{ ydb-short-name }} cluster.
 
 {% endnote %}
 
@@ -81,9 +81,9 @@ selector_config: []
 
 Detailed configuration parameters are described on the [{#T}](../../reference/configuration/index.md) page.
 
-By default, the cluster configuration gets version 1. When applying a new configuration, the uploaded configuration's version is compared with the value specified in the YAML file, and automatically incremented by one.
+By default, the cluster configuration is assigned version 1. When applying a new configuration, the system compares the uploaded configuration's version with the value specified in the YAML file. If the versions match, the current version number is automatically incremented by one.
 
-Below is a more complete and complex example of the dynamic configuration with the typical global parameters defined, as well as some parameters specific to a particular database:
+Below is a more comprehensive example of a dynamic configuration that defines typical global parameters, as well as parameters specific to a particular database:
 
 ```yaml
 ---

ydb/docs/en/core/reference/configuration/node_authorization.md

@@ -8,11 +8,11 @@ Below are the steps required to enable the node authorization feature.
 
 Before enabling the node authorization feature, you must [configure gRPC traffic encryption](./tls.md#grpc) using the TLS protocol.
 
-When preparing node certificates for a cluster in which you plan to use the node authorization feature, you must ensure uniform rules for filling in the "Subject" field of the certificates. When checking the certificate during node registration, {{ ydb-short-name }} verifies that the connecting node has a trusted certificate, and checks that the "Subject" field is filled in to ensure that it meets the requirements set in the cluster static configuration. The "Subject" field may contain multiple components (such as `O` - organization, `OU` - organizational division, `C` - country, `CN` - common name of the subject), and checks can be configured against one or more of these components.
+When preparing node certificates for a cluster where you plan to use the node authorization feature, ensure uniform rules for populating the "Subject" field of the certificates. During node registration, {{ ydb-short-name }} verifies that the connecting node has a trusted certificate and checks that the "Subject" field meets the requirements specified in the cluster's static configuration. The "Subject" field may contain multiple components (such as `O` - organization, `OU` - organizational unit, `C` - country, `CN` - common name), and checks can be configured against one or more of these components.
 
-The proposed [example script](https://github.com/ydb-platform/ydb/blob/main/ydb/deploy/tls_cert_gen/) generates the self-signed certiticates for {{ ydb-short-name }} nodes, and ensures that the "Subject" field is filled with value `O=YDB` for all node certificates. The examples of settings shown below are prepared for certificates with exactly this type of filling of the "Subject" field.
+The proposed [example script](https://github.com/ydb-platform/ydb/blob/main/ydb/deploy/tls_cert_gen/) generates self-signed certificates for {{ ydb-short-name }} nodes and ensures that the "Subject" field is populated with the value `O=YDB` for all node certificates. The settings examples provided below are prepared for certificates with this specific "Subject" field configuration, but feel free to use your real organization name instead.
 
-The command line parameters for [starting database nodes](../../devops/manual/initial-deployment.md#start-dynnode) must be extended to include the options that set the paths to the trusted CA certificate, the node certificate, and the node key files. The required extra command line options are shown in the table below.
+The command-line parameters for [starting database nodes](../../devops/manual/initial-deployment.md#start-dynnode) must include options that specify the paths to the trusted CA certificate, the node certificate, and the node key files. The required additional command-line options are shown in the table below.
 
 | **Command line option**    | **Description** |
 |----------------------------|-----------------|
@@ -33,11 +33,11 @@ Below is the example of the complete command to start the database node, with th
     --node-broker grpcs://<ydb3>:2135
 ```
 
-## Enabling database node authorization
+## Enabling database node authentication and authorization
 
-To enable the mandatory database node authorization, add the following configuration blocks to the [static cluster configuration](./index.md) file:
+To enable mandatory database node authorization, add the following configuration blocks to the [static cluster configuration](./index.md) file:
 
-1. Add the block `client_certificate_authorization` at the root level, and define the requirements for the "Subject" field of trusted node certificates, for example:
+1. At the root level, add the `client_certificate_authorization` block to define the requirements for the "Subject" field of trusted node certificates. For example:
 
     ```yaml
     client_certificate_authorization:
@@ -49,9 +49,9 @@ To enable the mandatory database node authorization, add the following configura
             values: ["YDB"]
     ```
 
-    If the certificate is successfully verified, and the components of the "Subject" field of the certificate comply with the requirements defined in the `subject_terms` sub-block, the connection will be assigned the access subjects listed in the `member_groups` parameter. To separate those subjects from other types of user groups and user accounts, their names typically get the `@cert` suffix.
+    If the certificate is successfully verified and the components of the "Subject" field comply with the requirements defined in the `subject_terms` sub-block, the connection will be assigned the access subjects listed in the `member_groups` parameter. To distinguish these subjects from other user groups and accounts, their names typically have the `@cert` suffix.
 
-1. Add the `register_dynamic_node_allowed_sids` element to `domains_config / security_config` block, and list the desired list of subjects which are enabled for database node registration. For internal technical reasons, the list of subjects must include the `root@builtin` element. Example:
+1. Add the `register_dynamic_node_allowed_sids` element to the `domains_config / security_config` block, and list the subjects permitted for database node registration. For internal technical reasons, the list must include the `root@builtin` element. Example:
 
     ```yaml
     domains_config: