Questions:

• SkuPriceId should reference the relevant published ListUnitPrice, and in cases with multiple tiers, it should correspond to the price associated with a specific tier, right?
• We've also established that SkuId MUST match SkuPriceId when a provider lacks an overarching SKU ID construct. What if a provider does support both SKU and SKU Price?, what additional properties, besides tier, should be associated with SKU Price rather than SKU?
• Do we plan to specify/impose that list of properties associated to the SKU Price and not SKU level. If the answer is yes and if a Provider can't provide SKU which is compliant with that, they should simply provide the same value for both SkuPriceId and SkuId or what?

I believe providers should define SKUs as different types of usage, meaningful from a DevOps perspective (i.e. can be monitored), to which additional dimensions might be added to define the price, like Tier and PricingCategory.
Maybe for Azure, SkuId could the combination of Azure MeterSubCategory and Meter, and SkuPriceId could be the combination of Azure PartNumber and PricingModel (would need to check the relationship diagram between them).

The problem I have is that I don't know what a "SKU" is for FOCUS. It's not clear as a provider what I should set the value to. And if I don't know, I'm pretty sure others won't either. At best, everyone will guess and we'll end up with inconsistent meanings for SkuId, which will make it meaningless. I don't think we need to require that SkuId have a specific set of attributes, but I do think we should say what it SHOULD include to make it clear what the intent is. As of right now, I could put absolutely anything in there and abide by the spec. That feels broken.

I feel this should be part of 1.0. Right now, it's not clear what value should be used for SkuId. Am I the only one?

I agree that SKU ID must be part of 1.0 and that its description as "a unique identifier that defines a provider-supported construct for organizing properties that are common across one or more SKU Prices" is somewhat abstract.

The description of a SKU Price ID as "a unique identifier that defines the unit price used to calculate the charge" might also seem awkward, as the term SKU is part of the name, but not of the description.

From the discussions that led to the current specification version, I understand that a SKU in FOCUS is in simple words what is purchased or used by a consumer, and what is charged to the consumer. This has been split in FOCUS into SKU ID (to identify the SKU) and into SKU Price ID (to identify the unit price), because a single SKU may have multiple prices, depending on other dimensions like Pricing Tier for example. Is it correct? If yes, I would propose indeed to reformulate the descriptions of SKU ID and SKU Price ID to link them more clearly to the core concept of SKU.

Action Items:

• TS2-#313-#314: Michael: To provide a list of SKU attributes and further expand on what constitutes a SKU ID.
• TS2-#313-#314: All Members: To prepare for a detailed discussion on SKU attributes and categorization next week.

As a practitioner, it is not immediately apparent to me that I would care too much about the actual SKU ID value and I could handle cross provider uniqueness by joining with Provider; however if providers can create SKU ID as something meaningful I am all for that.

Notes from Maintainers' call on November 4:

Context: The term “SKU ID” lacks a clear definition within the spec, leading to inconsistencies among providers and challenges for practitioners in aligning cost and usage data with external sources, such as pricing APIs. This item addresses those ambiguities.
Level of Effort Required: Medium — Clarifying the SKU ID definition is a relatively straightforward task but needs coordination with providers to ensure uniform understanding and application.
Level of Impact: Medium – Clear SKU ID definitions enable consistent alignment of cost and usage data across provider APIs, directly affecting the accuracy of financial reporting and integration with external pricing data, which is crucial for practitioners.

Comments from the Members' call on November 7:

#314: The group continued to work on classifying SKU properties, deciding to narrow down the focus to essential elements. Due to time constraints, an additional meeting was proposed to finalize which elements could be included in v1.2.

Action Items from TF-3 call on Nov 8:

• [#314] Task Force: Refine the definitions of SKU ID and SKU Price ID to resolve ambiguities.

Summary from the Maintainers' call on Nov 25

Context:
The purpose is to ensure that SKU IDs are clearly defined in the specification, addressing confusion about their usage and scope.
Maintainers Assigned:
Michael, Irena, Karl, Riley
Task Force Assigned:
Task Force 2 (TF2).

Next Steps from the TF-2 call on November 27:

• [#314] Irena @ijurica , Michael @flanakin : Collect existing provider mappings and definitions for SKU ID and SKU Price ID, including details on tiering, effective dates, and unit pricing.
• [#314] Michael @flanakin : Review internal Microsoft data and provide examples of SKU ID and SKU Price ID mappings to help refine definitions.
• [#314] David: Provide feedback on GCP’s usage of SKU ID and SKU Price ID, highlighting any discrepancies or challenges.
• [#314] Task Force: Schedule a focused discussion in the next TF3 meeting to review proposed definitions and provider mappings.
• [#314] All Members: Provide input on whether additional properties should be included to address provider-specific nuances (e.g., regional or tier data).
• [#314] Karl @flanakin : Share insights on how SKUs and pricing are handled in the retail industry to guide the clarification process.
• [#314] Irena @ijurica : Prepare a draft of the clarified definitions for SKU ID and SKU Price ID for initial review before the next TF3 meeting.

Action Items from the TF-2 Meeting on December 4:

• [#314] Karl @kk09v : Publish a poll to propose a few 1-hour time slots for next week to discuss #314: Clarify the Definition of SKU ID. Include the regular TF-2 meeting as one of the options.
• [#314] Joaquin @jpradocueva : Add the decision on the time slot to discuss #314 as a topic in the Maintainers Meeting agenda.
• [#314] Maintainers: Based on the poll results, decide on the meeting time at the next Maintainers Meeting - whether to schedule an ad-hoc meeting or allocate 1 hour during the next TF-2 meeting. This decision should also account for other complex TF-2 topics, such as backwards compatibility.
• [#314] Karl @kk09v : Share insights on how SKUs and pricing are handled in the retail industry at the ad-hoc meeting or next TF-2 meeting.
• [#314] Michael @flanakin : Review internal Microsoft data and provide examples of SKU ID and SKU Price ID mappings to help refine definitions. (Carried over from the previous meeting.)
• [#314] David: Provide feedback on GCP’s usage of SKU ID and SKU Price ID, highlighting any discrepancies or challenges. (Carried over from the previous meeting.)

Action Items from the Members' call on December 5.

• [#314] Karl @kk09v : Present an overview of SKU ID handling in the retail sector during the next meeting to inform the revised definition.
• [#314] Volunteer: Draft a revised SKU ID definition and share it with the group for feedback.
• [#314] Irena @ijurica : Ensure alignment of the revised SKU ID definition with related work items ([Work_Item] Add SKU and SKU Price properties (e.g. term, tier, SKU region) #619 and [Work_Item] Define change management principles to determine backwards compatibility #643).
• [#314] All members: Review the draft definition and prepare feedback for the ad-hoc meeting.
• [#314] Michael @flanakin : Schedule an ad-hoc meeting with cloud provider representatives to finalize the definition.

Action Items from the TF-2 call on December 11:

• [#314] Group: Categorize SKU-related properties into buckets for SKU ID and SKU Price ID.

Action Items from the Maintainers' call on December 16:

• [#314] Michael @flanakin : Cross-check the survey options and ensure all classification buckets are accurately represented in the spreadsheet Irena has created.

Action Items from the Maintainers' call on Jan 6:

• [[Work_Item] Clarify definition of SKU ID #314] Karl - Lead the discussion in the upcoming TF2 meeting to define a concrete action item for clarifying the SKU ID definition.

Action Items from the TF-2 call on Jan 8:

• [[Work_Item] Clarify definition of SKU ID #314] Irena @ijurica : Prepare a draft PR to clarify the definition of SKU ID, focusing on product specifications rather than pricing details.
• [[Work_Item] Clarify definition of SKU ID #314] Karl, @kk09v : Collaborate on Irena’s draft PR to refine the SKU ID and SKU Price ID definitions, ensuring alignment with CSP implementations.
• [[Work_Item] Clarify definition of SKU ID #314] All Members: Review and provide feedback on the draft proposal to finalize SKU ID and SKU Price ID classification before the consistency review on January 23.