From 67db63e63084091f8ddc39e2855e98b7d5d3a54c Mon Sep 17 00:00:00 2001
From: Joshua MacDonald <jmacd@lightstep.com>
Date: Thu, 3 Feb 2022 14:50:41 -0800
Subject: [PATCH 01/17] Specify preferred aggregation temporality

---
 specification/metrics/api.md |  4 +-
 specification/metrics/sdk.md | 82 +++++++++++++++++++++++++++---------
 2 files changed, 65 insertions(+), 21 deletions(-)

diff --git a/specification/metrics/api.md b/specification/metrics/api.md
index c5d75d81660..2a1852cfbac 100644
--- a/specification/metrics/api.md
+++ b/specification/metrics/api.md
@@ -404,7 +404,7 @@ observed. [OpenTelemetry API](../overview.md#api) authors SHOULD define whether
 this callback function needs to be reentrant safe / thread safe or not.
 
 Note: Unlike [Counter.Add()](#add) which takes the increment/delta value, the
-callback function reports the absolute value of the counter. To determine the
+callback function reports the cumulative value of the counter. To determine the
 reported rate the counter is changing, the difference between successive
 measurements is used.
 
@@ -893,7 +893,7 @@ observed. [OpenTelemetry API](../overview.md#api) authors SHOULD define whether
 this callback function needs to be reentrant safe / thread safe or not.
 
 Note: Unlike [UpDownCounter.Add()](#add-1) which takes the increment/delta value,
-the callback function reports the absolute value of the Asynchronous
+the callback function reports the cumulative value of the Asynchronous
 UpDownCounter. To determine the reported rate the Asynchronous UpDownCounter is
 changing, the difference between successive measurements is used.
 
diff --git a/specification/metrics/sdk.md b/specification/metrics/sdk.md
index 34dc46c3fcb..0c2def998b4 100644
--- a/specification/metrics/sdk.md
+++ b/specification/metrics/sdk.md
@@ -179,7 +179,8 @@ are the inputs:
     apply a [default aggregation](#default-aggregation). If the aggregation
     outputs metric points that use aggregation temporality (e.g. Histogram,
     Sum), the SDK SHOULD handle the aggregation temporality based on the
-    temporality of each [MetricReader](#metricreader) instance.
+    [preferred aggregation temporality](#preferred-aggregation-temporality) 
+	of each [MetricReader](#metricreader) instance.
   * The `exemplar_reservoir` (optional) to use for storing exemplars.
     This should be a factory or callback similar to aggregation which allows
     different reservoirs to be chosen by the aggregation.
@@ -622,25 +623,68 @@ The SDK SHOULD provide a way to allow `MetricReader` to respond to
 idiomatic approach, for example, as `OnForceFlush` and `OnShutdown` callback
 functions.
 
+### Preferred aggregation temporality
+
 The SDK SHOULD provide a way to allow the preferred [Aggregation
-Temporality](./datamodel.md#temporality) to be specified for a `MetricReader`
-instance during the setup (e.g. initialization, registration, etc.) time. If the
-preferred temporality is explicitly specified then the SDK SHOULD respect that,
-otherwise use Cumulative.
-
-[OpenTelemetry SDK](../overview.md#sdk)
-authors MAY choose the best idiomatic design for their language:
-
-* Whether to treat the temporality settings as recommendation or enforcement.
-  For example, if the temporality is set to Delta, would the SDK want to perform
-  Cumulative->Delta conversion for an [Asynchronous
-  Counter](./api.md#asynchronous-counter), or downgrade it to a
-  [Gauge](./datamodel.md#gauge), or keep consuming it as Cumulative due to the
-  consideration of [memory
-  efficiency](./supplementary-guidelines.md#memory-management)?
-* Refer to the [supplementary
-  guidelines](./supplementary-guidelines.md#aggregation-temporality), which have
-  more context and suggestions.
+Temporality](./datamodel.md#temporality) to be specified for a
+`MetricReader` instance during the setup (e.g. initialization,
+registration, etc.) time.  This preference gives the user control over
+the amount of long-term memory dedicated to reading metrics, and has
+considerable cost implications.
+
+The synchronous instruments generally define data points having
+aggregation temporality (e.g., `Sum`, `Histogram`).  For these points,
+when a `MetricReader` is configured with Cumulative aggregation
+temporality, there is an implied long-term memory cost.  The preferred
+aggregation temporality is meant to give users control over this cost.
+
+The asynchronous `Counter` and `UpDownCounter` instruments are defined
+by observations having cumulative aggregation temporality to begin
+with.  For these points, a change of aggregation temporality implies
+conversion from Cumulative into Delta aggregation temporality.
+
+Because of these differences, synchronous and asynchronous instruments
+are given separate treatment.  When configuring the preferred
+aggregation temporality, the implementation MUST provide at least the
+following named preferences:
+
+- "Cumulative": All data points that define the concept are exported
+  with Cumulative aggregation temporality (i.e., all data point kinds
+  except for `Gauge`).  This implies maintaining long-term Cumulative 
+  state for metric streams deriving from synchronous instruments.
+- "Stateless": Data points that define the concept deriving from
+  synchonous instruments are exported with Delta aggregation
+  temporality (e.g., Delta `Sum` and Delta `Histogram` points), while
+  data points that define the concept deriving from asynchronous
+  instruments are exported with Cumulative aggregation temporality.
+  This preference is so named because it avoids long-term memory costs
+  in the SDK for metrics.
+
+If the preferred temporality is explicitly specified then the SDK
+SHOULD respect that, otherwise use Cumulative.
+
+A configured `MetricReader` instance MUST support reading the
+preferred aggregation temporality for synchronous instruments.
+
+An optional aggregation temporality preference "Delta" MAY be
+supported by implementations, making it possible for users to convert
+data points from asynchronous `UpDownCounter` and `Counter`
+instruments into Delta aggregation temporality inside their SDK.
+
+SDK support for converting Cumulative to Delta aggregation is optional
+because it is not considered widely useful; in metrics data formats
+that emphasize Delta aggregation temporality such as StatsD, it is
+conventional to convert cumulative values into `Gauge` data points,
+for example, and this is not typically encountered for `Histogram`
+measurements.
+
+Users that wish to convert Cumulative into Delta aggregation
+temporality may consider using an [OpenTelemetry Collector metrics
+processor meant for this purpose](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/cumulativetodeltaprocessor).
+
+Refer to the [supplementary
+guidelines](./supplementary-guidelines.md#aggregation-temporality),
+which have more context and suggestions.
 
 ### MetricReader operations
 

From a0fe16a09ca2fe523636e7b9a36b432a98e9961a Mon Sep 17 00:00:00 2001
From: Joshua MacDonald <jmacd@lightstep.com>
Date: Thu, 3 Feb 2022 16:00:38 -0800
Subject: [PATCH 02/17] edit

---
 CHANGELOG.md                 |  1 +
 specification/metrics/sdk.md | 20 +++++++++-----------
 2 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 821833cb3ba..06c8933c1ec 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -41,6 +41,7 @@ release.
   [#2032](https://github.com/open-telemetry/opentelemetry-specification/pull/2061)
 - Changed default Prometheus Exporter host from `0.0.0.0` to `localhost`.
   ([#2282](https://github.com/open-telemetry/opentelemetry-specification/pull/2282))
+- Clarify what is meant by "preferred" aggregation temporality.
 
 ### Logs
 
diff --git a/specification/metrics/sdk.md b/specification/metrics/sdk.md
index 0c2def998b4..7b4d5214053 100644
--- a/specification/metrics/sdk.md
+++ b/specification/metrics/sdk.md
@@ -629,19 +629,17 @@ The SDK SHOULD provide a way to allow the preferred [Aggregation
 Temporality](./datamodel.md#temporality) to be specified for a
 `MetricReader` instance during the setup (e.g. initialization,
 registration, etc.) time.  This preference gives the user control over
-the amount of long-term memory dedicated to reading metrics, and has
-considerable cost implications.
+the amount of long-term memory dedicated to reading metrics.
 
 The synchronous instruments generally define data points having
 aggregation temporality (e.g., `Sum`, `Histogram`).  For these points,
 when a `MetricReader` is configured with Cumulative aggregation
-temporality, there is an implied long-term memory cost.  The preferred
-aggregation temporality is meant to give users control over this cost.
+temporality, there is an implied long-term memory cost.
 
 The asynchronous `Counter` and `UpDownCounter` instruments are defined
-by observations having cumulative aggregation temporality to begin
-with.  For these points, a change of aggregation temporality implies
-conversion from Cumulative into Delta aggregation temporality.
+by observations that are cumulative values to begin with.  For these
+points, a change of aggregation temporality implies conversion from
+Cumulative into Delta aggregation temporality.
 
 Because of these differences, synchronous and asynchronous instruments
 are given separate treatment.  When configuring the preferred
@@ -652,13 +650,13 @@ following named preferences:
   with Cumulative aggregation temporality (i.e., all data point kinds
   except for `Gauge`).  This implies maintaining long-term Cumulative 
   state for metric streams deriving from synchronous instruments.
-- "Stateless": Data points that define the concept deriving from
+- "Stateless": Data points having aggregation temporality deriving from
   synchonous instruments are exported with Delta aggregation
   temporality (e.g., Delta `Sum` and Delta `Histogram` points), while
-  data points that define the concept deriving from asynchronous
+  data points having aggregation temporality deriving from asynchronous
   instruments are exported with Cumulative aggregation temporality.
-  This preference is so named because it avoids long-term memory costs
-  in the SDK for metrics.
+  This preference is so named because it avoids long-term Cumulative 
+  state in the metrics SDK.
 
 If the preferred temporality is explicitly specified then the SDK
 SHOULD respect that, otherwise use Cumulative.

From c3baa5771b5fc8742654a7d8c4ca4ff1fec7bd27 Mon Sep 17 00:00:00 2001
From: Joshua MacDonald <jmacd@lightstep.com>
Date: Thu, 3 Feb 2022 16:05:48 -0800
Subject: [PATCH 03/17] PR num

---
 CHANGELOG.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 06c8933c1ec..75937fb4176 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -42,6 +42,7 @@ release.
 - Changed default Prometheus Exporter host from `0.0.0.0` to `localhost`.
   ([#2282](https://github.com/open-telemetry/opentelemetry-specification/pull/2282))
 - Clarify what is meant by "preferred" aggregation temporality.
+  ([#2314](https://github.com/open-telemetry/opentelemetry-specification/pull/2314))
 
 ### Logs
 

From eea4d5c5011218914ba8f966dd62ec07282908fc Mon Sep 17 00:00:00 2001
From: Joshua MacDonald <jmacd@users.noreply.github.com>
Date: Fri, 4 Feb 2022 08:38:45 -0800
Subject: [PATCH 04/17] Update specification/metrics/api.md

Co-authored-by: Georg Pirklbauer <georg.pirklbauer@dynatrace.com>
---
 specification/metrics/api.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/specification/metrics/api.md b/specification/metrics/api.md
index 2a1852cfbac..9e62db51cbf 100644
--- a/specification/metrics/api.md
+++ b/specification/metrics/api.md
@@ -405,8 +405,8 @@ this callback function needs to be reentrant safe / thread safe or not.
 
 Note: Unlike [Counter.Add()](#add) which takes the increment/delta value, the
 callback function reports the cumulative value of the counter. To determine the
-reported rate the counter is changing, the difference between successive
-measurements is used.
+reported rate at which the counter is changing, the difference between successive
+measurements should be used.
 
 The callback function SHOULD NOT take indefinite amount of time. If multiple
 independent SDKs coexist in a running process, they MUST invoke the callback

From ca93c51c420cc5bd281a212878b3ef9a69dcb7a2 Mon Sep 17 00:00:00 2001
From: Joshua MacDonald <jmacd@lightstep.com>
Date: Wed, 16 Feb 2022 11:08:25 -0800
Subject: [PATCH 05/17] revert spurious API diff

---
 CHANGELOG.md                 | 2 ++
 specification/metrics/api.md | 4 ++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index ada57d9b753..bf24b9606f9 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -20,6 +20,8 @@ release.
 - Introduce the concept of Instrumentation Scope to replace/extend Instrumentation
   Library. The Meter is now associated with Instrumentation Scope
   ([#2276](https://github.com/open-telemetry/opentelemetry-specification/pull/2276)).
+- Clarify what is meant by "preferred" aggregation temporality.
+  ([#2314](https://github.com/open-telemetry/opentelemetry-specification/pull/2314))
 
 ### Logs
 
diff --git a/specification/metrics/api.md b/specification/metrics/api.md
index e05bfaf36a9..9cc5b5d1374 100644
--- a/specification/metrics/api.md
+++ b/specification/metrics/api.md
@@ -407,8 +407,8 @@ this callback function needs to be reentrant safe / thread safe or not.
 
 Note: Unlike [Counter.Add()](#add) which takes the increment/delta value, the
 callback function reports the cumulative value of the counter. To determine the
-reported rate at which the counter is changing, the difference between successive
-measurements should be used.
+reported rate the counter is changing, the difference between successive
+measurements is used.
 
 The callback function SHOULD NOT take indefinite amount of time. If multiple
 independent SDKs coexist in a running process, they MUST invoke the callback

From f68782227e8c940cf13cbb39e7884e60d42fae55 Mon Sep 17 00:00:00 2001
From: Joshua MacDonald <jmacd@lightstep.com>
Date: Wed, 16 Feb 2022 12:37:27 -0800
Subject: [PATCH 06/17] clarify 5-way function & two named prefs

---
 specification/metrics/sdk.md | 79 ++++++++++++++++--------------------
 1 file changed, 34 insertions(+), 45 deletions(-)

diff --git a/specification/metrics/sdk.md b/specification/metrics/sdk.md
index 61adc55506e..f6fb9b310bb 100644
--- a/specification/metrics/sdk.md
+++ b/specification/metrics/sdk.md
@@ -629,14 +629,14 @@ functions.
 
 The SDK SHOULD provide a way to allow the preferred [Aggregation
 Temporality](./datamodel.md#temporality) to be specified for a
-`MetricReader` instance during the setup (e.g. initialization,
-registration, etc.) time.  This preference gives the user control over
-the amount of long-term memory dedicated to reading metrics.
+`MetricReader` instance during setup (e.g. initialization,
+registration, etc.). This preference gives the SDK user control over the
+amount of long-term memory dedicated to reading metrics.
 
 The synchronous instruments generally define data points having
 aggregation temporality (e.g., `Sum`, `Histogram`).  For these points,
-when a `MetricReader` is configured with Cumulative aggregation
-temporality, there is an implied long-term memory cost.
+a `MetricReader` configured with Cumulative aggregation temporality
+implies conversion from Delta into Cumulative aggregation temporality.
 
 The asynchronous `Counter` and `UpDownCounter` instruments are defined
 by observations that are cumulative values to begin with.  For these
@@ -645,46 +645,35 @@ Cumulative into Delta aggregation temporality.
 
 Because of these differences, synchronous and asynchronous instruments
 are given separate treatment.  When configuring the preferred
-aggregation temporality, the implementation MUST provide at least the
-following named preferences:
-
-- "Cumulative": All data points that define the concept are exported
-  with Cumulative aggregation temporality (i.e., all data point kinds
-  except for `Gauge`).  This implies maintaining long-term Cumulative 
-  state for metric streams deriving from synchronous instruments.
-- "Stateless": Data points having aggregation temporality deriving from
-  synchonous instruments are exported with Delta aggregation
-  temporality (e.g., Delta `Sum` and Delta `Histogram` points), while
-  data points having aggregation temporality deriving from asynchronous
-  instruments are exported with Cumulative aggregation temporality.
-  This preference is so named because it avoids long-term Cumulative 
-  state in the metrics SDK.
-
-If the preferred temporality is explicitly specified then the SDK
-SHOULD respect that, otherwise use Cumulative.
-
-A configured `MetricReader` instance MUST support reading the
-preferred aggregation temporality for synchronous instruments.
-
-An optional aggregation temporality preference "Delta" MAY be
-supported by implementations, making it possible for users to convert
-data points from asynchronous `UpDownCounter` and `Counter`
-instruments into Delta aggregation temporality inside their SDK.
-
-SDK support for converting Cumulative to Delta aggregation is optional
-because it is not considered widely useful; in metrics data formats
-that emphasize Delta aggregation temporality such as StatsD, it is
-conventional to convert cumulative values into `Gauge` data points,
-for example, and this is not typically encountered for `Histogram`
-measurements.
-
-Users that wish to convert Cumulative into Delta aggregation
-temporality may consider using an [OpenTelemetry Collector metrics
-processor meant for this purpose](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/cumulativetodeltaprocessor).
-
-Refer to the [supplementary
-guidelines](./supplementary-guidelines.md#aggregation-temporality),
-which have more context and suggestions.
+aggregation temporality for a `MetricReaderExporter`, the
+implementation MUST provide a mechanism that supports configuring the
+exporter's preferred temporality on the basis of instrument kind for
+the five instruments `Counter`, `Asynchronous Counter`,
+`UpDownCounter`, `Asynchronous UpDownCounter`, and `Histogram`.
+
+A configured `MetricReader` instance MUST expose data in the preferred
+aggregation temporality for points deriving from the five instruments
+that define aggregation temporality.
+
+Two well-known preferences are named, offering a simple way to express
+exporter preferences through environment variables and in
+configuration files.  The following named preferences SHOULD be
+supported:
+
+- **AllCumulative**: All data points with aggregation temporality are
+  exported using Cumulative aggregation temporality. 
+- **DeltaPreferred**: Data points from `Counter`, `Asynchronous
+  Counter`, and `Histogram` instruments use Delta aggregation
+  temporality, whereas whereas data points from `UpDownCounter` and
+  `Asynchronous UpDownCounter` are exported with Cumualtive
+  aggregation temporality.
+
+If the preferred temporality is not explicitly specified, the SDK
+SHOULD use the AllCumulative aggregation temporality preference.
+
+Refer to the [data model section on Stream
+Manipulations](datamodel.md#stream-manipulations) for more detail on
+changing aggregation temporality.
 
 ### MetricReader operations
 

From a8fe8f98633322f344279006a0e43f60cc9c85f8 Mon Sep 17 00:00:00 2001
From: Joshua MacDonald <jmacd@lightstep.com>
Date: Wed, 16 Feb 2022 12:44:59 -0800
Subject: [PATCH 07/17] cumulative->current

---
 specification/metrics/api.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/specification/metrics/api.md b/specification/metrics/api.md
index 9cc5b5d1374..f4e916a418c 100644
--- a/specification/metrics/api.md
+++ b/specification/metrics/api.md
@@ -406,7 +406,7 @@ observed. [OpenTelemetry API](../overview.md#api) authors SHOULD define whether
 this callback function needs to be reentrant safe / thread safe or not.
 
 Note: Unlike [Counter.Add()](#add) which takes the increment/delta value, the
-callback function reports the cumulative value of the counter. To determine the
+callback function reports the current value of the counter. To determine the
 reported rate the counter is changing, the difference between successive
 measurements is used.
 
@@ -895,7 +895,7 @@ observed. [OpenTelemetry API](../overview.md#api) authors SHOULD define whether
 this callback function needs to be reentrant safe / thread safe or not.
 
 Note: Unlike [UpDownCounter.Add()](#add-1) which takes the increment/delta value,
-the callback function reports the cumulative value of the Asynchronous
+the callback function reports the current value of the Asynchronous
 UpDownCounter. To determine the reported rate the Asynchronous UpDownCounter is
 changing, the difference between successive measurements is used.
 

From c0789de99ec6f76746d54e6008442cbbc1798c2a Mon Sep 17 00:00:00 2001
From: Joshua MacDonald <jmacd@users.noreply.github.com>
Date: Tue, 22 Feb 2022 07:47:03 -0800
Subject: [PATCH 08/17] Apply suggestions from code review

Co-authored-by: Alan West <3676547+alanwest@users.noreply.github.com>
---
 specification/metrics/sdk.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/specification/metrics/sdk.md b/specification/metrics/sdk.md
index f6fb9b310bb..0f51018570e 100644
--- a/specification/metrics/sdk.md
+++ b/specification/metrics/sdk.md
@@ -645,7 +645,7 @@ Cumulative into Delta aggregation temporality.
 
 Because of these differences, synchronous and asynchronous instruments
 are given separate treatment.  When configuring the preferred
-aggregation temporality for a `MetricReaderExporter`, the
+aggregation temporality for a `MetricReader`, the
 implementation MUST provide a mechanism that supports configuring the
 exporter's preferred temporality on the basis of instrument kind for
 the five instruments `Counter`, `Asynchronous Counter`,
@@ -664,8 +664,8 @@ supported:
   exported using Cumulative aggregation temporality. 
 - **DeltaPreferred**: Data points from `Counter`, `Asynchronous
   Counter`, and `Histogram` instruments use Delta aggregation
-  temporality, whereas whereas data points from `UpDownCounter` and
-  `Asynchronous UpDownCounter` are exported with Cumualtive
+  temporality, whereas data points from `UpDownCounter` and
+  `Asynchronous UpDownCounter` are exported with Cumulative
   aggregation temporality.
 
 If the preferred temporality is not explicitly specified, the SDK

From 271866e7fe4acc0b018154942efb9a67ba9467be Mon Sep 17 00:00:00 2001
From: Joshua MacDonald <jmacd@lightstep.com>
Date: Wed, 2 Mar 2022 15:03:40 -0800
Subject: [PATCH 09/17] blank

---
 CHANGELOG.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index bb6bcabb9ff..19744c1da33 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -29,7 +29,6 @@ release.
 - Clarify what is meant by "preferred" aggregation temporality.
   ([#2314](https://github.com/open-telemetry/opentelemetry-specification/pull/2314))
 
-
 ### Logs
 
 ### Resource

From 6e3b8922351fed4bd3dd340f19e1a36a1070a963 Mon Sep 17 00:00:00 2001
From: Joshua MacDonald <jmacd@lightstep.com>
Date: Wed, 2 Mar 2022 15:25:01 -0800
Subject: [PATCH 10/17] rephrase per jack-berg and alanwest

---
 specification/metrics/sdk.md | 70 +++++++++++++++++++-----------------
 1 file changed, 38 insertions(+), 32 deletions(-)

diff --git a/specification/metrics/sdk.md b/specification/metrics/sdk.md
index 66a39ebf25a..db475d19f84 100644
--- a/specification/metrics/sdk.md
+++ b/specification/metrics/sdk.md
@@ -348,12 +348,12 @@ to select an aggregation and configuration parameters.
 
 | Instrument Kind | Selected Aggregation |
 | --- | --- |
-| [Counter](./api.md#counter) | [Sum Aggregation](./sdk.md#sum-aggregation) |
-| [Asynchronous Counter](./api.md#asynchronous-counter) | [Sum Aggregation](./sdk.md#sum-aggregation) |
-| [UpDownCounter](./api.md#updowncounter) | [Sum Aggregation](./sdk.md#sum-aggregation) |
-| [Asynchrounous UpDownCounter](./api.md#asynchronous-updowncounter) | [Sum Aggregation](./sdk.md#sum-aggregation) |
+| [Counter](./api.md#counter) | [Sum Aggregation](./sdk.md#sum-aggregation) with preferred temporality strategy |
+| [Asynchronous Counter](./api.md#asynchronous-counter) | [Sum Aggregation](./sdk.md#sum-aggregation) with preferred temporality strategy |
+| [UpDownCounter](./api.md#updowncounter) | [Sum Aggregation](./sdk.md#sum-aggregation) with cumulative temporality strategy |
+| [Asynchrounous UpDownCounter](./api.md#asynchronous-updowncounter) | [Sum Aggregation](./sdk.md#sum-aggregation) with cumulative temporality strategy |
 | [Asynchronous Gauge](./api.md#asynchronous-gauge) | [Last Value Aggregation](./sdk.md#last-value-aggregation) |
-| [Histogram](./api.md#histogram) | [Histogram Aggregation](./sdk.md#histogram-aggregation) |
+| [Histogram](./api.md#histogram) | [Histogram Aggregation](./sdk.md#histogram-aggregation) with preferred temporality strategy |
 
 This Aggregation does not have any configuration parameters.
 
@@ -373,7 +373,9 @@ The monotonicity of the aggregation is determined by the instrument type:
 | [Asynchronous Counter](./api.md#asynchronous-counter) | Monotonic |
 | [Asynchrounous UpDownCounter](./api.md#asynchronous-updowncounter) | Non-Monotonic |
 
-This Aggregation does not have any configuration parameters.
+This Aggregation the following configuration parameters:
+
+- Aggregation temporality `strategy` [determines how the temporality choice is made](#preferred-aggregation-temporality).
 
 This Aggregation informs the SDK to collect:
 
@@ -397,7 +399,9 @@ The Histogram Aggregation informs the SDK to select the best Histogram
 Aggregation available. i.e. [Explicit Bucket Histogram
 Aggregation](./sdk.md#explicit-bucket-histogram-aggregation).
 
-This Aggregation does not have any configuration parameters.
+This Aggregation has the following configuration parameters:
+
+- Aggregation temporality `strategy` [determines how the temporality choice is made](#preferred-aggregation-temporality).
 
 #### Explicit Bucket Histogram Aggregation
 
@@ -419,6 +423,7 @@ This Aggregation informs the SDK to collect:
 instruments that record negative measurements, e.g. `UpDownCounter` or `ObservableGauge`.
 - Min (optional) `Measurement` value in population.
 - Max (optional) `Measurement` value in population.
+- Aggregation temporality `strategy` [determines how the temporality choice is made](#preferred-aggregation-temporality).
 
 ### Observations inside asynchronous callbacks
 
@@ -691,33 +696,34 @@ by observations that are cumulative values to begin with.  For these
 points, a change of aggregation temporality implies conversion from
 Cumulative into Delta aggregation temporality.
 
-Because of these differences, synchronous and asynchronous instruments
-are given separate treatment.  When configuring the preferred
-aggregation temporality for a `MetricReader`, the
-implementation MUST provide a mechanism that supports configuring the
-exporter's preferred temporality on the basis of instrument kind for
-the five instruments `Counter`, `Asynchronous Counter`,
-`UpDownCounter`, `Asynchronous UpDownCounter`, and `Histogram`.
-
-A configured `MetricReader` instance MUST expose data in the preferred
-aggregation temporality for points deriving from the five instruments
-that define aggregation temporality.
-
-Two well-known preferences are named, offering a simple way to express
-exporter preferences through environment variables and in
-configuration files.  The following named preferences SHOULD be
-supported:
-
-- **AllCumulative**: All data points with aggregation temporality are
-  exported using Cumulative aggregation temporality. 
-- **DeltaPreferred**: Data points from `Counter`, `Asynchronous
-  Counter`, and `Histogram` instruments use Delta aggregation
-  temporality, whereas data points from `UpDownCounter` and
-  `Asynchronous UpDownCounter` are exported with Cumulative
-  aggregation temporality.
+Because of these differences, when configuring Aggregations that
+support aggregation temporality, there is a choice of Aggregation
+temporality strategy.
+
+Typically (and by default), `UpDownCounter` instruments are converted
+to Cumulative temporality, ignoring the `MetricReader` preference.
+
+The Aggregation temporality preference of the `MetricReader` combined
+with the Aggregation temporality strategy of the `Aggregation`
+determines the exported aggregation temporality.
+
+The two supported `Aggregation` temporality strategies are:
+
+- **Cumulative**: The Aggregation Temporality will be selected as
+  Cumulative, overriding the `MetricReader` preference.
+- **Preferred**: The Aggregation Temporality will be selected
+  according to the `MetricReader` preference.
+
+Three `MetricReader` preferences are available:
+
+- **Cumulative**: The Metric Exporter prefers Cumulative temporality.
+- **Delta**: The Metric Exporter prefers Delta temporality.
+- **Stateless**: The Metric Exporter prefers Delta temporality for
+synchronous instruments and Cumulative temporality for asynchronous
+instruments to avoid long-term memory.
 
 If the preferred temporality is not explicitly specified, the SDK
-SHOULD use the AllCumulative aggregation temporality preference.
+SHOULD use the Cumulative aggregation temporality preference.
 
 Refer to the [data model section on Stream
 Manipulations](datamodel.md#stream-manipulations) for more detail on

From c20fb6f23f290f58864cd896c89662d583878843 Mon Sep 17 00:00:00 2001
From: Joshua MacDonald <jmacd@lightstep.com>
Date: Wed, 2 Mar 2022 15:26:48 -0800
Subject: [PATCH 11/17] lint

---
 specification/metrics/sdk.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/specification/metrics/sdk.md b/specification/metrics/sdk.md
index db475d19f84..82cab35501a 100644
--- a/specification/metrics/sdk.md
+++ b/specification/metrics/sdk.md
@@ -27,6 +27,7 @@
   * [ExemplarReservoir](#exemplarreservoir)
   * [Exemplar defaults](#exemplar-defaults)
 - [MetricReader](#metricreader)
+  * [Preferred aggregation temporality](#preferred-aggregation-temporality)
   * [MetricReader operations](#metricreader-operations)
     + [Collect](#collect)
     + [Shutdown](#shutdown-1)

From 98bae8781c58c7fc203719d2242dd16e30995758 Mon Sep 17 00:00:00 2001
From: Joshua MacDonald <jmacd@users.noreply.github.com>
Date: Thu, 3 Mar 2022 10:18:59 -0800
Subject: [PATCH 12/17] Update specification/metrics/sdk.md

Co-authored-by: Alan West <3676547+alanwest@users.noreply.github.com>
---
 specification/metrics/sdk.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specification/metrics/sdk.md b/specification/metrics/sdk.md
index 82cab35501a..f18355525fc 100644
--- a/specification/metrics/sdk.md
+++ b/specification/metrics/sdk.md
@@ -374,7 +374,7 @@ The monotonicity of the aggregation is determined by the instrument type:
 | [Asynchronous Counter](./api.md#asynchronous-counter) | Monotonic |
 | [Asynchrounous UpDownCounter](./api.md#asynchronous-updowncounter) | Non-Monotonic |
 
-This Aggregation the following configuration parameters:
+This Aggregation has the following configuration parameters:
 
 - Aggregation temporality `strategy` [determines how the temporality choice is made](#preferred-aggregation-temporality).
 

From 8e88e9e45895c5441021b1c07be54964e924901c Mon Sep 17 00:00:00 2001
From: Joshua MacDonald <jmacd@lightstep.com>
Date: Fri, 4 Mar 2022 09:21:00 -0800
Subject: [PATCH 13/17] remove stateless

---
 specification/metrics/sdk.md | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/specification/metrics/sdk.md b/specification/metrics/sdk.md
index 82cab35501a..cefd4d7864d 100644
--- a/specification/metrics/sdk.md
+++ b/specification/metrics/sdk.md
@@ -719,9 +719,6 @@ Three `MetricReader` preferences are available:
 
 - **Cumulative**: The Metric Exporter prefers Cumulative temporality.
 - **Delta**: The Metric Exporter prefers Delta temporality.
-- **Stateless**: The Metric Exporter prefers Delta temporality for
-synchronous instruments and Cumulative temporality for asynchronous
-instruments to avoid long-term memory.
 
 If the preferred temporality is not explicitly specified, the SDK
 SHOULD use the Cumulative aggregation temporality preference.

From 77e5fdf715e19f6b92a32d02f3e66073861b265e Mon Sep 17 00:00:00 2001
From: Joshua MacDonald <jmacd@lightstep.com>
Date: Fri, 4 Mar 2022 09:23:16 -0800
Subject: [PATCH 14/17] update changelog

---
 CHANGELOG.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 19744c1da33..3d369c205a5 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -26,7 +26,9 @@ release.
   ([#2317](https://github.com/open-telemetry/opentelemetry-specification/pull/2317)).
 - Clarify that expectations for user callback behavior are documentation REQUIREMENTs.
   ([#2361](https://github.com/open-telemetry/opentelemetry-specification/pull/2361)).
-- Clarify what is meant by "preferred" aggregation temporality.
+- Clarify what is meant by "preferred" aggregation temporality.  Introduce aggregation
+  strategy to Sum, Histogram, and ExponentialHistogram Aggregations, for use in 
+  View configuration to override the exporter preference.
   ([#2314](https://github.com/open-telemetry/opentelemetry-specification/pull/2314))
 
 ### Logs

From c5a5a74a9ddd8cd03b03ad8ddc0dc2c5df3406f8 Mon Sep 17 00:00:00 2001
From: Joshua MacDonald <jmacd@lightstep.com>
Date: Fri, 4 Mar 2022 11:01:51 -0800
Subject: [PATCH 15/17] add preference in OTLP exporter

---
 specification/metrics/sdk_exporters/otlp.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/specification/metrics/sdk_exporters/otlp.md b/specification/metrics/sdk_exporters/otlp.md
index 1060b3b0a5a..e1c0fceb83f 100644
--- a/specification/metrics/sdk_exporters/otlp.md
+++ b/specification/metrics/sdk_exporters/otlp.md
@@ -1,4 +1,4 @@
-# OpenTelemetry Metrics Exporter - OTLP
+1# OpenTelemetry Metrics Exporter - OTLP
 
 **Status**: [Stable](../../document-status.md)
 
@@ -9,12 +9,12 @@ Exporter](../sdk.md#push-metric-exporter) which sends metrics via the
 OTLP Metrics Exporter MUST support both Cumulative and Delta
 [Temporality](../datamodel.md#temporality).
 
-OTLP Metrics Exporter MUST allow [Aggregation
-Temporality](../datamodel.md#temporality) to be specified, as described in
-[MetricExporter](../sdk.md#metricexporter).
+OTLP Metrics Exporter MUST allow [Preferred Aggregation
+Temporality](../datamodel.md#preferred-aggregation-temporality) to be specified, as described in
+[MetricReader](../sdk.md#metricreader).
 
-If the temporality is not specified, OTLP Metrics Exporter SHOULD use Cumulative
-as the default temporality.
+If the temporality preference is not specified, OTLP Metrics Exporter SHOULD use Cumulative
+as the default aggregation temporality preference.
 
 The exporter MUST provide configuration according to the [OpenTelemetry Protocol
 Exporter](../../protocol/exporter.md) specification.

From 1a2d3717dd6ae6540bef3ae954db80825590d8ec Mon Sep 17 00:00:00 2001
From: Joshua MacDonald <jmacd@lightstep.com>
Date: Fri, 4 Mar 2022 11:02:06 -0800
Subject: [PATCH 16/17] typo

---
 specification/metrics/sdk.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/specification/metrics/sdk.md b/specification/metrics/sdk.md
index a635aad0b2a..06d82c2ac41 100644
--- a/specification/metrics/sdk.md
+++ b/specification/metrics/sdk.md
@@ -715,7 +715,7 @@ The two supported `Aggregation` temporality strategies are:
 - **Preferred**: The Aggregation Temporality will be selected
   according to the `MetricReader` preference.
 
-Three `MetricReader` preferences are available:
+Two `MetricReader` preferences are available:
 
 - **Cumulative**: The Metric Exporter prefers Cumulative temporality.
 - **Delta**: The Metric Exporter prefers Delta temporality.

From 6f4965d87434c902084783f0fa4ccf7ab87b77dc Mon Sep 17 00:00:00 2001
From: Joshua MacDonald <jmacd@lightstep.com>
Date: Fri, 4 Mar 2022 14:01:30 -0800
Subject: [PATCH 17/17] revert api change

---
 specification/metrics/api.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/specification/metrics/api.md b/specification/metrics/api.md
index 9d63416bcc9..f616630921b 100644
--- a/specification/metrics/api.md
+++ b/specification/metrics/api.md
@@ -501,7 +501,7 @@ pattern](https://en.wikipedia.org/wiki/Asynchronous_method_invocation) and
 See the [general requirements for asynchronous instruments](#asynchronous-instrument-api).
 
 Note: Unlike [Counter.Add()](#add) which takes the increment/delta value, the
-callback function reports the current value of the counter. To determine the
+callback function reports the absolute value of the counter. To determine the
 reported rate the counter is changing, the difference between successive
 measurements is used.
 
@@ -970,7 +970,7 @@ pattern](https://en.wikipedia.org/wiki/Asynchronous_method_invocation) and
 See the [general requirements for asynchronous instruments](#asynchronous-instrument-api).
 
 Note: Unlike [UpDownCounter.Add()](#add-1) which takes the increment/delta value,
-the callback function reports the current value of the Asynchronous
+the callback function reports the absolute value of the Asynchronous
 UpDownCounter. To determine the reported rate the Asynchronous UpDownCounter is
 changing, the difference between successive measurements is used.