Move configuration documents to configuration folder

CHANGELOG.md

@@ -54,6 +54,9 @@ release.
   ([#3360](https://github.com/open-telemetry/opentelemetry-specification/pull/3360))
 - Move file configuration schema to `opentelemetry-configuration`.
   ([#3412](https://github.com/open-telemetry/opentelemetry-specification/pull/3412))
+- Move `sdk-configuration.md` and `sdk-environment-variables.md`
+  to `/specification/configuration/`.
+  ([#3434](https://github.com/open-telemetry/opentelemetry-specification/pull/3434))
 
 ### Telemetry Schemas
 

specification/README.md

@@ -33,7 +33,7 @@ cascade:
   - [Metrics](metrics/sdk.md)
   - [Logs](logs/sdk.md)
   - [Resource](resource/sdk.md)
-  - [Configuration](sdk-configuration.md)
+  - [Configuration](configuration/sdk-configuration.md)
 - Data Specification
   - [Semantic Conventions](overview.md#semantic-conventions)
   - [Protocol](protocol/README.md)

specification/configuration/file-configuration.md

@@ -19,9 +19,9 @@
 
 File configuration provides a mechanism for configuring OpenTelemetry which is
 more expressive and full-featured than
-the [environment variable](../sdk-environment-variables.md) based scheme, and
+the [environment variable](sdk-environment-variables.md) based scheme, and
 language agnostic in a way not possible
-with [programmatic configuration](../sdk-configuration.md#programmatic).
+with [programmatic configuration](sdk-configuration.md#programmatic).
 
 File configuration defines a [Configuration Model](#configuration-model),
 which can be expressed in a [configuration file](#configuration-file).

specification/sdk-configuration.md → specification/configuration/sdk-configuration.md

@@ -8,6 +8,8 @@
 - [Abstract](#abstract)
 - [Configuration Interface](#configuration-interface)
   * [Programmatic](#programmatic)
+  * [Environment Variables](#environment-variables)
+  * [Configuration File](#configuration-file)
   * [Other Mechanisms](#other-mechanisms)
 
 <!-- tocstop -->
@@ -34,6 +36,14 @@ struct on an SDK builder class. From that, one could build a CLI that accepts a
 file (YAML, JSON, TOML, ...) and then transforms into that well-defined struct
 consumable by the programmatic interface.
 
+### Environment Variables
+
+See [OpenTelemetry Environment Variable Specification](./sdk-environment-variables.md).
+
+### Configuration File
+
+See [File Configuration](./file-configuration.md).
+
 ### Other Mechanisms
 
 Additional configuration mechanisms SHOULD be provided in whatever

specification/metrics/sdk.md

@@ -1262,7 +1262,7 @@ If a batch of [Metric points](./data-model.md#metric-points) can include
 ## Defaults and configuration
 
 The SDK MUST provide configuration according to the [SDK environment
-variables](../sdk-environment-variables.md) specification.
+variables](../configuration/sdk-environment-variables.md) specification.
 
 ## Numerical limits handling
 

specification/metrics/sdk_exporters/in-memory.md

@@ -16,6 +16,6 @@ In-memory Metrics Exporter MUST support both Cumulative and Delta
 If a language provides a mechanism to automatically configure a
 [MetricReader](../sdk.md#metricreader) to pair with the associated
 exporter (e.g., using the [`OTEL_METRICS_EXPORTER` environment
-variable](../../sdk-environment-variables.md#exporter-selection)), by
+variable](../../configuration/sdk-environment-variables.md#exporter-selection)), by
 default the exporter MUST be paired with a [periodic exporting
 MetricReader](../sdk.md#periodic-exporting-metricreader).

specification/metrics/sdk_exporters/otlp.md

@@ -21,7 +21,7 @@ Exporter](../../protocol/exporter.md) specification.
 If a language provides a mechanism to automatically configure a
 [MetricReader](../sdk.md#metricreader) to pair with the associated
 Exporter (e.g., using the [`OTEL_METRICS_EXPORTER` environment
-variable](../../sdk-environment-variables.md#exporter-selection)),
+variable](../../configuration/sdk-environment-variables.md#exporter-selection)),
 then by default:
 
 * The exporter MUST be paired with a [periodic exporting

specification/metrics/sdk_exporters/stdout.md

@@ -20,7 +20,7 @@ StreamExporter, etc.
 If a language provides a mechanism to automatically configure a
 [MetricReader](../sdk.md#metricreader) to pair with the associated
 exporter (e.g., using the [`OTEL_METRICS_EXPORTER` environment
-variable](../../sdk-environment-variables.md#exporter-selection)), by
+variable](../../configuration/sdk-environment-variables.md#exporter-selection)), by
 default the exporter MUST be paired with a [periodic exporting
 MetricReader](../sdk.md#periodic-exporting-metricreader)
 with a default `exportIntervalMilliseconds` of 10000.

specification/resource/semantic_conventions/README.md

@@ -52,7 +52,7 @@ Given their significance some resource attributes are treated specifically as de
 ### Semantic Attributes with Dedicated Environment Variable
 
 These are the attributes which MAY be configurable via a dedicated environment variable
-as specified in [OpenTelemetry Environment Variable Specification](../../sdk-environment-variables.md):
+as specified in [OpenTelemetry Environment Variable Specification](../../configuration/sdk-environment-variables.md):
 
 - [`service.name`](#service)
 

specification/vendors.md

@@ -20,7 +20,7 @@ The OpenTelemetry project consists of both a
 [specification](https://github.com/open-telemetry/opentelemetry-specification)
 for the API, SDK, protocol and semantic conventions, as well as an
 implementation of each for a number of languages. The default SDK implementation
-is [highly configurable](sdk-configuration.md) and extendable, for example
+is [highly configurable](configuration/sdk-configuration.md) and extendable, for example
 through [Span Processors](trace/sdk.md#span-processor), to allow for additional
 logic needed by particular vendors to be added without having to implement a
 custom SDK. By not requiring a custom SDK means for most languages a user will

specification/versioning-and-stability.md

@@ -247,7 +247,7 @@ instrumentations can use schemas to change the instrumentation they produce.
 
 **Exception:** Some resource attributes are embedded in various locations of the
 Specification, e.g. the `service.*` attributes which are required by SDKs to be
-produced and have corresponding [environment variables defined in general SDK configuration](sdk-environment-variables.md#general-sdk-configuration). These resource
+produced and have corresponding [environment variables defined in general SDK configuration](configuration/sdk-environment-variables.md#general-sdk-configuration). These resource
 attributes MUST NOT be ever changed. They are considered a hard-coded part of
 this specification.