provide more motivation content & alternatives

Signed-off-by: Joey Brown <[email protected]>

text/0000-export-run-image-metadata.md

@@ -12,12 +12,16 @@
 # Summary
 [summary]: #summary
 
-The `report.toml` file created by the lifecycle exporter and rebaser should include `run-image.image`, `run-image.reference`, and `run-image.top-layer`. These values can be critical to a platform rebase process.
+The `report.toml` file created by the lifecycle exporter and rebaser should include `run-image.image`, `run-image.reference`, and `run-image.top-layer`. These values are not necessarily known prior to export or rebase they can be critical to a platform rebase process.
 
 # Motivation
 [motivation]: #motivation
 
-When publishing an image directly to a registry, parsing the [`lifecycle.metadata` label](https://github.com/buildpacks/spec/blob/main/platform.md#iobuildpackslifecyclemetadata-json) is inefficient--it requires a call to the registry after the image is published. Adding these values to `report.toml` lets platforms efficiently access this data after an export or rebase without a call to the registry.
+Platform operators may need a comprehensive understanding of images on their platform in order to make decisions about rebase and image publishing. Run image metadata is likely part of this comprehensive understanding for rebase. It is likely that this data may only be known after an image is created or rebased, and today it is only accessible via reading the image. Therefore, in order to access this metadata, platform operators must query the image.
+
+Querying the docker daemon or querying an image registry is suboptimal and we should make this data more accessible. It is suboptimal because it requires the platform to run an additional service to query the data it just published. If we make this data more accessible, we could potentially reduce image queries (registry calls) calls by a significant factor.
+
+Putting this data into `report.toml` is advantageous over other methods, especially when considering the kubernetes `terminationMessagePath` message [pattern](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#pod-v1-core). In this pattern, the content of `report.toml` can be used as a container's termination message, making this data easily accessible after an image is exported or rebased within a kubernetes container.
 
 # What it is
 [what-it-is]: #what-it-is
@@ -69,19 +73,27 @@ This is an additive change to a metadata file and will be backwards compatible.
 # Drawbacks
 [drawbacks]: #drawbacks
 
-This metadata is written to the [`lifecycle.metadata` label](https://github.com/buildpacks/spec/blob/main/platform.md#iobuildpackslifecyclemetadata-json). It can be accessed by querying the config from docker daemon or registry. So we will be writing this data to two outputs.
+This metadata is written to the [`lifecycle.metadata` label](https://github.com/buildpacks/spec/blob/main/platform.md#iobuildpackslifecyclemetadata-json) and it can be accessed by querying a docker daemon or registry. So we will be writing this data to two outputs.
 
 # Alternatives
 [alternatives]: #alternatives
 
-Do nothing and continue to require platforms to retrieve this information via alternative means--either querying the docker daemon or registry.
+1. Do nothing and continue to require platforms to retrieve this information via alternative means--either querying the docker daemon or registry.
+    - Rebase process may remain suboptimal for some platform providers.
+
+2. Write all the metadata labels to `report.toml`.
+    - This could break platform operators that are using the `terminationMessagePath` [pattern](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#pod-v1-core). Because some of the metadata includes unbounded arrays, we could explode this report beyond the max size of 4096 bytes.
 
-Introduce a new output file (`lifecycle-metadata.toml?`) that contains everything in [`lifecycle.metadata` label](https://github.com/buildpacks/spec/blob/main/platform.md#iobuildpackslifecyclemetadata-json).
+3. Write another file that contains this metadata (and potentially more metadata).
+    - If we consider this approach and take it to the logical conclusion, we should consider writing a sparse image as output. A sparse image would contain all the metadata available, and it would be in a well-known format that other image tools like `crane`, `skopeo`, or `pack` can read.
+    - Writing to another file is not as simple as writing to `report.toml`.
+      - It increases the complexity of lifecycle exporter & rebaser. 
+      - Writing to another file would not give platform operators the advantage of the `terminationMessagePath` [pattern](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#pod-v1-core), because they are likely already reading `report.toml`.
 
 # Prior Art
 [prior-art]: #prior-art
 
-These values are among those that `pack inspect` returns.
+These values are written to image labels. And they are among values that `pack inspect` returns.
 
 # Unresolved Questions
 [unresolved-questions]: #unresolved-questions