FOCUS #319: Track (sometimes differing) commitment burndown units separately from consumed quantity/unit columns

[cnharris10]

Key Points

• Adds 3 new columns to track CSP commitments: CommitmentConsumedQuantity, CommitmentTotalQuantity, CommitmentConsumedUnit
  • WE SHOULD DEBATE BETTER COLUMN NAMES
• Specifies that ConsumedQuantity and ConsumedUnit MUST be NULL with an unused commitment row. (reference pr)
• Specifies that {List,Contracted}{UnitPrice,Cost} and PricingUnit should match values from purchase records ... and PricingQuantity should match the quantity unused for an unused commitment row.
• Specifies that ResourceId MUST be null for an unused commitment row
• Further scopes the defintion of commitment-based discount within the glossary.

UPDATE (8/16/24)

1. Columns renamed to: CommitmentDiscountConsumedQuantity, CommitmentDiscountUnit, CommitmentDiscountPurchaseQuantity
2. {List,Contracted}UnitPrice, Pricing{Quantity,Unit} are null when CommitmentDiscountStatus:Unused
3. {List,Contracted}Cost are 0 when CommitmentDiscountStatus:Unused
4. New, official glossary terms incorporated from FinOps page for commitment-based discount and negotiated discount

UPDATE (8/19/24)

1. {List,Contracted}{Cost,UnitPrice} and Pricing{Quantity,Unit} columns now 0 or null when CommitmentDiscountStatus:Unused (TO BE DISCUSSED in TF-1)
2. {List,Contracted}{Cost,UnitPrice} and Pricing{Quantity,Unit} columns now in bullet-list format.
3. Correction-based normative text added by Irena.
4. This pr exists to renaming all instances of /commitment[\-,\s]?based\sdiscount/i to commitment discount (with correct casing)

Discussion Points (8/20/24)

1. 2 current views for columns: {List,Contracted}{Cost,UnitPrice} and Pricing{Quantity,Unit} when CommitmentDiscountStatus:Unused a. Set all values to appropriate null or 0 values (current). b. Set all values to the same values as the purchase record (if it exists).
2. Currently, PricingCategory MUST be "Committed" when [CommitmentDiscountId](#commitmentdiscountid) is not null. Should this be changed to Standard for Purchase rows where the CommitmentDiscountId is the ResourceId?
3. With commitment/negotiated discount definitions altered, is it clear that current/planned CommitmentDiscount* columns are relevant for commitment discounts and not negotiated discounts?

UPDATE (8/21/24)

1. Includes a recurring purchase for each charge period of the term for No/Partial Upfront commitments

• No Upfront Purchase - has all units for the charge period
• Partial Upfront Purchase - has 1/2 of the units for each charge period

2. Reverts changing guidance around these {List,Contracted}{Cost,UnitPrice} and Pricing{Quantity,Unit} columns.
3. Adds additional guidance commitment discount purchase is one-time vs. recurring
4. Adds additional phrasing to differentiate commitment vs negotiated discounts in each CommitmentDiscount* column.
5. Removes edit to resource name to further minimize pr size (for now)

Update (8/22/24)

1. Changes to the ResourceId column have been reverted (no clause for ResourceId to be null with an unused commitment discount)

Sample Data

https://docs.google.com/spreadsheets/d/1AYDPZ4rl90PPEbyQJUaGCUSwZ4s_sfy-8sO2KyNq0aM/edit?pli=1&gid=1976106562#gid=1976106562

Normative Text (original version, adopted into pr)

https://docs.google.com/spreadsheets/d/1AYDPZ4rl90PPEbyQJUaGCUSwZ4s_sfy-8sO2KyNq0aM/edit?pli=1&gid=464941124#gid=464941124

[jpradocueva]

• [ ] TF1-#400 : Michael Flanakin: Analyze current data and provide insights on deriving commitment utilization metrics.
• [ ] TF1-#400 : Chris: Document the goals of the commitment utilization data and provide an analysis.

[cnharris10]

@marc-perreaut This pr will be influenced by the outcome of the "Cakes" vs. "Ingredients" debate. For now, you can see a list of open questions here: https://docs.google.com/spreadsheets/d/1zA0brhrEntfWlzt5VNcNLBFnKPEiarajTF84o4ATeEw/edit?gid=1705742856#gid=1705742856

[jpradocueva]

Last Agreement:

#400 Commitment Utilization and Normalization ~[ON HOLD]~ Maintainer: Chris Documents: Usage vs Pricing Quantity and unit examples AI: Current Status: Waiting for the resolution of the related action items before proceeding.

• [ ] TF1-#400 : Chris: Document the goals of the commitment utilization data and provide an analysis.

• [ ] TF1-#400 : Michael: Analyze current data and provide insights on deriving commitment utilization metrics.

• [ ] TF-1 Chris: Add detailed examples of commitment utilization and update the group.

Action Items

The group agreed to resume this topic.

• [ ] TF1-#400 Irena and Chris: To prepare and provide more use cases and examples.

Action Items

Suggested during the Maintainers' call on July 22:

• [ ] Maintainers-#400: Chris and Irina to prepare and present sample data and discussion points in the upcoming meeting to highlight key concerns and potential solutions.

Action Items, TF-1, Jul 23 call:

• Modeling and Testing: Continue modeling different commitment types to identify and resolve potential issues.
• Charge Category Definition: Determine appropriate charge categories for recurring charges associated with commitments.
• Data Specification: Ensure the data specification supports accurate and meaningful representation of commitments and their usage.
• Normalization Implementation: Explore the implementation of normalization factors and new columns for commitment quantity and commitment unit.

Next Steps:

• Continue discussions and modeling efforts to refine the handling of commitment data.
• Engage with relevant stakeholders to validate and finalize the proposed solutions.
• Focus on practical use case scenarios to ensure the proposed changes address real-world requirements effectively.

Action Items, Maintainers call, July 29

• [ ] TF1-#400 Chris to draft a proposal incorporating feedback from members.

Action Items, Task Force 1, July 30

• [ ] TF1-#400 Riley and Chris: Set up a call to discuss the extension of the current model to include intermediary currencies and additional use cases. The discussion will take place on the Slack channel: “tf-commitment-utilization”
• [ ] TF1-#400 Chris and Team: Refine the proposal, ensuring that use cases are well-documented and aligned with the normative text changes.
• [ ] TF1-#400 All Members: Review the proposal and provide feedback on the feasibility of the proposed changes, focusing on the potential implications for backward compatibility and the handling of normalization across different commitment types.

Action Items from the Maintainers meeting on Aug 5th:

• [ ] [Maintainers-#400] Chris to provide a summary in the TF1 chat and include concerns about supporting token-based models.
• [ ] [Maintainers-#400] Team to review Chris’s update and provide feedback.

1. Update and Clarify Documentation:

• Update the documentation to specify that commitments combined with negotiations are not included in the current scope.
• Provide clear definitions and examples for fixed interval commitments and how they should be tracked (allocated to the task force).

2. Review and Finalize Normative Documentation:

• Fill in the details for the "normative origin" sheet and review it before the next meeting (allocated to Irena).
• Schedule a 30-minute review session before the next meeting to discuss the normative documentation and ensure alignment.

3. Prepare for Future Changes:

• Plan to address OCI commitments and other non-CSP commitments in future versions, ensuring the schema can be retrofitted or expanded as needed.

4. Gather Feedback on Editorial Changes:

• Send an email to the group requesting feedback on editorial changes and provide necessary documentation for review (allocated to the task force leader).

5. Schedule Next Meeting:

• Ensure the next meeting focuses on reviewing the proposed changes and finalizing the schema for fixed interval commitments.

Action Items from TF-1 call on Aug 6th:

• [ ] [TF1-#400] Chris to draft a definition for group one and group two commitments and post in the working group for feedback.
• [ ] [TF1-#400] Irina to assist with clarifying normative text for the current columns and proposed changes.
• [ ] [TF1-#400]The team to review the proposed classifications and provide input on the next steps.
• [ ] [TF1-#400] Chris and Irina to ensure the updated definitions and classifications are incorporated into the next release documentation.

Action Items from TF-1 call on Aug 13th:

• [ ] [TF1-#400] Chris to lead an ad hoc meeting focused on resolving the remaining ambiguities around commitment-based discounts, scheduled for 9:00 am Eastern the following day.
• [ ] [TF1-#400] All members to review the PR and provide feedback, particularly on the sections that are vague, controversial, or require further clarification. -[ ] [TF1-#400] Irena to provide feedback on the PR before the next TF1 meeting.

Action Items, Maintainers, Aug 15:

• [ ] [Members-#400] Chris to continue refining the PR with feedback, and the team to work on clarifying the FinOps framework definitions.

[thecloudman]

@cnharris10 is the data in current columns ConsumedQuantity, ConsumedUnit not enough to work this out? Adding additional columns with possibly replicated data is only going to bloat the dataset size.

[cnharris10]

@cnharris10 is the data in current columns ConsumedQuantity, ConsumedUnit not enough to work this out? Adding additional columns with possibly replicated data is only going to bloat the dataset size.

@thecloudman See differing quantities and units in columns D-H in the sample data for more context.

[ijurica]

Commitment Utilization related columns

Nullability overview:

ChargeCategory	ChargeClass	CommitmentDiscountId	CommitmentStatus	CommitmentConsumedQuantity	CommitmentTotalQuantity	CommitmentConsumedUnit
Usage	(null)	not null	Used	MUST NOT be null	MUST be null ?	MUST NOT be null
Usage	Correction	not null	Used	MAY be null	MUST be null ?	MAY be null
Usage	(null)	not null	Unused	MUST NOT be null	MUST be null ?	MUST NOT be null
Usage	Correction	not null	Unused	MAY be null	MUST be null ?	MAY be null
Purchase	(null)	not null	MUST be null ?	MUST be null	MUST NOT be null	MUST NOT be null
Purchase	Correction	not null	MUST be null ?	MUST be null	MAY be null	MAY be null
Credit			MUST be null	MUST be null	MUST be null	MUST be null
Adjustment			MUST be null	MUST be null	MUST be null	MUST be null
Tax			MUST be null	MUST be null	MUST be null	MUST be null

Questions:

• Need confirmation that commitment-based discounts can't be applied to Purchase records.

CommitmentConsumedUnit - normative paragraph suggestion

The ConsumedQuantity column adheres to the following requirements:

• CommitmentConsumedUnit MUST be present in a FOCUS dataset when the provider supports commitment-based discounts.
• CommitmentConsumedUnit MUST NOT be null if either CommitmentConsumedQuantity or CommitmentTotalQuantity is not null.
• CommitmentConsumedUnit MUST be null if both CommitmentConsumedQuantity and CommitmentTotalQuantity are null.

Naming

• Keep in mind that CommitmentConsumedUnit complements both CommitmentConsumedQuantity and CommitmentTotalQuantity.

Column Definitions

• Based on the current definition, CommitmentTotalQuantity seems a bit underutilized especially if we have no ability to get the CommitmentTotalQuantity in case of No-Upfront Payment-Model.

[ijurica]

After some thought, I've switched to the "ListCost and ContractedCost equals 0 in case of unused usage" camp (@cnharris10 that’s what you initially proposed, right?).

REASONING:

Both of these fields provide information on what you would have paid if you hadn’t purchased a commitment-based discount, correct? If that’s true, then if you hadn’t purchased the commitment-based discount, you wouldn’t have paid anything.

Therefore, I believe that:

• ListCost and ContractedCost MUST be 0 when CommitmentDiscountStatus is "Unused."
• PricingQuantity, PricingUnit, ListUnitPrice, and ContractedUnitPrice MUST be null when CommitmentDiscountStatus is "Unused". (similar to the simplification in the case of Tax)

[cnharris10]

After some thought, I've switched to the "ListCost and ContractedCost equals 0 in case of unused usage" camp (@cnharris10 that’s what you initially proposed, right?).

REASONING:

Both of these fields provide information on what you would have paid if you hadn’t purchased a commitment-based discount, correct? If that’s true, then if you hadn’t purchased the commitment-based discount, you wouldn’t have paid anything.

Therefore, I believe that:

• ListCost and ContractedCost MUST be 0 when CommitmentDiscountStatus is "Unused."

• PricingQuantity, PricingUnit, ListUnitPrice, and ContractedUnitPrice MUST be null when CommitmentDiscountStatus is "Unused". (similar to the simplification in the case of Tax)

Yes, this was the initial proposal because the context of the row is around what was not amortized and nothing about the purchase IMHO

[jpradocueva]

Action Items, TF-1, Aug 20:

• [ ] [TF1-#400] Chris @cnharris10 : To reintegrate the previous line item model into the sample data for review.
• [ ] [TF1-#400] All members: To provide feedback on the proposed changes after reviewing the updated sample data.
• [ ] [TF1-#400] Irena @ijurica : To propose a new PR addressing the constraint on pricing categories related to commitment discounts.

[rileyjenk]

I think this may be a good item for us to include some examples in the example section in the appendix.

[cnharris10]

I think this may be a good item for us to include some examples in the example section in the appendix.

Plan to subsequently after this goes in.

[jpradocueva]

Action Items, Members call on Aug 22:

• [ ] [Members-#400-#524] Chris @cnharris10 : To finalize and merge PR #524; group to continue reviewing PR #400.

[jpradocueva]

Action Items from Maintainers' call on Aug 26:

• [ ] [Maintainers-#400] Chris - @cnharris10 and Tim - @timwright2000: To discuss the PR offline and finalize it before Thursday.
• [ ] [Maintainers-#400] Zach - @AWS-ZachErdman and Michael - @flanakin : To review the PR content on time for Thursday, Aug 29 meeting

[AWS-ZachErdman]

I read the column descriptions and started going through the sample data which is very detailed, but I'm wondering if there is any documentation anywhere that clearly explains the use case of these columns?

It wasn't immediately obvious to me what the advantage of adding these is over just using Pricing and ConsumedQuantity. I'd really like a strong justification for adding more usage quantity columns that sound similar to others and could lead to confusion.

[cnharris10]

I read the column descriptions and started going through the sample data which is very detailed, but I'm wondering if there is any documentation anywhere that clearly explains the use case of these columns?

It wasn't immediately obvious to me what the advantage of adding these is over just using Pricing and ConsumedQuantity. I'd really like a strong justification for adding more usage quantity columns that sound similar to others and could lead to confusion.

Thanks Zach. The list of use-cases in the same sheet as the sample data under tab: "Use-Cases" and the most complete sample data (right now) is in tab: "Sample Data - Commitment Discounts".

I've detailed some of the high-level points that TF-1 gained consensus on over the past few months as well:

1. Differing consumption values
   In 2 of 3 cases, the consumed units (and quantities) between commitments and resources are different.

• RI (zonal) ✅
  • Consumed Unit -> Hours
  • Commitment Consumed Unit -> Hours
• RI (regional) ❌
  • Consumed Unit -> Hours
  • Commitment Consumed Unit -> Normalized Hours
• Savings Plans ❌
  • Consumed Unit -> Hours
  • Commitment Consumed Unit -> <Currency>

2. Separation of consumption between resources & commitments Based on the above point, the group felt that including unused commitment quantity values within Consumed{Quantity,Unit} columns was:

• A denormalization, and Consumed{Quantity,Unit} are resource-intended quantities.
• In the case of spend-based commitments (ex: Savings Plans), showing an unused $$$ quantity wasn't valid.
• Showing the difference unused hours (i.e. ChargePeriodEnd - ChargePeriodStart) was invalid and/or not useful.

3. Cakes vs. Ingredients approach The group considered just adding a normalization factor at one point to allow derivation of commitment quantities (i.e. the "Ingredients" approach), but decided not to go this route for a couple reasons:

• For a practitioner with N providers, ensuring that all providers are supported by FOCUS columns (or x_) columns did not seem like a scalable path forward.
• Requiring practitioners be knowledgable about and do this derivation across N providers at scale seemed counterproductive to FOCUS itself. In most cases, practitioners just want the finalized numbers, and for those who want to dive deeper, providers can choose to supply additional documentation. -- For these reasons, the group settled on the "cake-based" approach of providing these columns and leaving it to the provider to provide documentations for breaking down these numbers for the smaller group of individuals needing to go this route.

[jpradocueva]

[TF1-#400] Chris - @cnharris10 : Implement any final changes and submit the PR for approval.

[jpradocueva]

Action Items from Members' call on Aug 29:

• [ ] [Maintainers-#400] Tim - @timwright2000 Work with Chris to explore alternative proposals that address the concerns. [Maintainers-#400] Chris - @cnharris10 : Prepare a revised proposal based on Tim's resolution to his objection for the next meeting

[ijurica]

Update (8/31/24)

Given that this pr was not fully approved on 8/30, and there was considerable feedback (but less time) to merge CommitmentDiscountConsumedQuantity and CommitmentDiscountPurchasedQuantity into 1 column, I've gone ahead with this change to form column: CommitmentDiscountQuantity.

Practitioners can stil filter to purchases and committed usage like:

• Purchases: ChargeCategory = 'Purchase' AND CommitmentDiscountId IS NOT NULL
• Committed Usage (Used): ChargeCategory = 'Usage' AND CommitmentDiscountStatus = 'Used' AND CommitmentDiscountId IS NOT NULL
• Committed Usage (Unused): ChargeCategory = 'Usage' AND CommitmentDiscountStatus = 'Unused' AND CommitmentDiscountId IS NOT NULL.

This change is meant to reduce the number of proposed columns without changing any (meaningful) intent of the previous versions with 2 quantity columns. The last commit to this pr encapsulates this entire change and can be backed out if the group does not approve of this iteration.

👍 Totally agree! And it aligns with the PricingQuantity/PricingUnit concept, etc

[jpradocueva]

Action Items from Maintainers call on Feb 2nd:

• [ ] [Maintainers-#400] Chris, @cnharris10 : To draft a term in the glossary related to size normalization and add clauses to the quantity column indicating normalization.
• [ ] [Maintainers-#400] All Members: To review the suggested editorial changes, especially those related to normalization, and provide feedback before the next meeting.
• [ ] [Maintainers-#400] Irena, @ijurica : To provide specific examples of sample data reflecting normalization for review in the next meeting.
• [ ] [Maintainers-#400] Chris, @cnharris10 and Irena, @ijurica : To meet before the TF1 meeting to discuss the sample data and any lingering concerns regarding double counting and normalization factors.

[jpradocueva]

Action Items from TF-1 call on Sep 3:

• [ ] [TF1-#400] Chris, @cnharris10: Finalize the merge of the two quantity columns and update the documentation to reflect this change.
• [ ] [TF1-#400] Chris, @cnharris10: Push the draft commit related to size flexibility and present it at the next meeting for further review.
• [ ] [TF1-#400] All Members: Review the changes once the commit is pushed and provide feedback before the next meeting.

[jpradocueva]

Action Items from TF-2 call on Sep 4:

• [ ] [TF2-#400] All: Review PR #400 in light of SKU details and provide feedback in the next session.

[rileyjenk]

I put my suggestions in, here is an explanation of my thinking.

TLDR: I believe that we should hold on supporting normalized units until v1.2. Normalization for size flexibility, capacity planning, and other use cases is critically important to get right. This approach is going the right direction, but it isn't comprehensive enough. As proposed it would only support Compute, but not Databases like RDS, nor size flexibility that exists outside of compute spheres (KB, MB, GB, TB etc...). I believe supporting it is achievable but needs more refinement.

More detailed Thoughts

• I hesitate on introducing normalization as either/or option to the provider, this states that for size flexibility it is normalized but for other cases it is not (often I need both to make decisions)
• Size flexibility is not the only reason to provide normalization, data sizes, capacity planning etc....
• Normalization is subject to the whims of the provider and service handles it differently (aws RDS multi az vs non az is an example)
• SAAS commitment models will require a more generalized approach
• I don't want to introduce normalization in earlier to the point that it makes implementing a more generally applicable normalization approach more complicated
• I don't want to intro a column naming convention that indicates the column is normalized isn't totally accurate because we have normalization requirements without the naming convention

[cnharris10]

I put my suggestions in, here is an explanation of my thinking.

TLDR: I believe that we should hold on supporting normalized units until v1.2. Normalization for size flexibility, capacity planning, and other use cases is critically important to get right. This approach is going the right direction, but it isn't comprehensive enough. As proposed it would only support Compute, but not Databases like RDS, nor size flexibility that exists outside of compute spheres (KB, MB, GB, TB etc...). I believe supporting it is achievable but needs more refinement.

More detailed Thoughts

• I hesitate on introducing normalization as either/or option to the provider, this states that for size flexibility it is normalized but for other cases it is not (often I need both to make decisions)
• Size flexibility is not the only reason to provide normalization, data sizes, capacity planning etc....
• Normalization is subject to the whims of the provider and service handles it differently (aws RDS multi az vs non az is an example)
• SAAS commitment models will require a more generalized approach
• I don't want to introduce normalization in earlier to the point that it makes implementing a more generally applicable normalization approach more complicated
• I don't want to intro a column naming convention that indicates the column is normalized isn't totally accurate because we have normalization requirements without the naming convention

"As proposed it would only support Compute, but not Databases like RDS" --> This is incorrect, RDS also has instances, instance families, and instance types. See arrows below.

"nor size flexibility that exists outside of compute spheres (KB, MB, GB, TB etc...)" --> No provider supports this. There is no intention of making a perfect size-flex model in this proposal. That is a waste of time.

The additional bullet points express opinions of preference, many lacking truth unless data can be produced to show otherwise or superfluous to the scope of this proposal, that do not support building the spec in iteration. As is, this proposal completes the commitment discount story for FOCUS, provides a giant step forward from 1.0, and there is no assurance that additional normalization support is scheduled for 1.2 - meaning full support of commitment discounts might be a year+ away.

Given there are 5 hours before the next ratification over the 3 month process to get here, I am only in favor of altering the text presented to propose size-flexibility more generally that can be expanded on later, but I object completely to any removal of normalization based on the points provided above.

"NEQG88H6AT5KKSYZ" : {
      "sku" : "NEQG88H6AT5KKSYZ",
      "productFamily" : "Database Instance",
      "attributes" : {
        "servicecode" : "AmazonRDS",
        "location" : "EU (Ireland)",
        "locationType" : "AWS Region",
        "instanceType" : "db.z1d.6xlarge", <------
        "currentGeneration" : "Yes",
        "instanceFamily" : "Memory optimized", <------
        "vcpu" : "24",
        "physicalProcessor" : "Intel Xeon Platinum 8151",
        "memory" : "192 GiB",
        "storage" : "1 x 900 NVMe SSD",
        "networkPerformance" : "10,000 Mbps",
        "processorArchitecture" : "64-bit",
        "engineCode" : "5",
        "databaseEngine" : "Oracle",
        "databaseEdition" : "Enterprise",
        "licenseModel" : "Bring your own license",
        "deploymentOption" : "Multi-AZ",
        "usagetype" : "EU-Multi-AZUsage:db.z1d.6xl",
        "operation" : "CreateDBInstance:0005",
        "instanceTypeFamily" : "Z1D", <------
        "normalizationSizeFactor" : "96",  <------
        "regionCode" : "eu-west-1",
        "servicename" : "Amazon Relational Database Service"
      }
    }

[ijurica]

CommitmentDiscountQuantity is a cake, just like EffectiveCost and by not going into too much detail, we should be able to reach consensus on the introduced terms while maintaining flexibility in the definition to cover all standard commitment discount use cases—an important first step.

This is the action plan I would suggest:

1. Focus on getting approval for this PR.

2. Move the content of both commitment utilization-related appendix PRs into the supporting content, and reference those files in the supporting content of the CommitmentQuantityDiscount column. I believe it’s better to have this valuable content in the supporting content for v1.1, rather than leaving it in an open PR. This way, it will be accessible to both practitioners and providers, and in v1.2, we can push it back into the spec and seek feedback, approval, etc.

3. Move the size-flexibility description paragraph from the column spec into the supporting content, replacing it with a single sentence that highlights the distinction between this and other quantity columns due to size-flexibility. This is what I've previously suggested but I'm open to suggestions and we need to agree on the actual term: Unlike Pricing Quantity and Consumed Quantity, Commitment Discount Quantity includes commitment discount size flexibility.

4. Move the size-flexibility terms from the glossary to the supporting content as well. By including that description/example (or however we choose to categorize it), both providers and practitioners will understand how we plan to use this column. Anyone interested can continue refining it even after the Consistency review phase.

[rileyjenk]

RDS has more than just size for normalization and size flexibility as it relates to reservations. Specifically they have both size and if the resource and RI are multi AZ or not.

[jpradocueva]

Action Items from TF-3 call on Sep 6:

• [ ] [TF3-#400] All Members: Review the concerns about including normalized quantities and prepare to discuss potential solutions in the next meeting.
• [ ] [TF3-#400] Riley, @rileyjenk : Provide specific use cases or data scenarios illustrating issues with the current normalization proposal.
• [ ] [TF3-#400] Alex, @ahullah : Explore potential mechanisms for declaring normalization that address the raised concerns.
• [ ] [TF3-#400] Chris, @cnharris10 and Irena, @ijurica : Reevaluate the proposal to see if adjustments can be made, such as modifying naming conventions or documentation, to mitigate concerns.
• [ ] [TF3-#400] Michael, @flanakin : Continue resolving remaining issues and update the team on progress.

[jpradocueva]

Action Items:

• [ ] [Maintainers-#400] Riley, @rileyjenk : Provide data samples and feedback on the proposed normalization column.
• [ ] [Maintainers-#400] Chris, @cnharris10 : Draft the new column definition, ensuring it accommodates size flexibility and non-size flexible cases.
• [ ] [Maintainers-#400] Irena, @ijurica : Review AWS zonal reservation data and update the normalization logic based on the discussion.
• [ ] [Maintainers-#400] All members: Continue reviewing and providing feedback on the normalization approach before the next meeting.

[jpradocueva]

Action Items:

• [ ] [TF1-#400] Chrism, @cnharris10 : Review final draft to ensure the removal of specific instance terms and generalize commitment discount guidelines.
• [ ] [TF1-#400] Shawn, @salpaysenturus : Provide updated text on commitment discount quantities, focusing on flexibility in provider-specific scenarios.

[jpradocueva]

Approved by the group on Members call on Sep 12.

[jpradocueva]

Action Items from Members' call on Sep 12:

• [ ] [TF2-#400] Chris, @cnharris10 : Prepare and submit the supporting content as a follow-up.