SkuId is not clear

[flanakin]

Type

Dimension: SkuId Normalized: No

Description:

A SKU ID is an unique identifier that defines a provider-supported construct for organizing properties that are common across one or more SKU Prices. SKU ID can be referenced on a catalog or price list published by a provider to look up detailed information about the SKU. The composition of the properties associated with the SKU ID may differ across providers. Some providers may not support the SKU construct and instead associate all such properties directly with the SKU Price. SKU ID is commonly used for analyzing cost based on SKU related properties above the pricing constructs.

Description

As a provider, I don't know what value to use for SkuId. The description is not explicit enough in what the value represents. Given there are many attributes for a SKU that make it unique, the description needs to be more precise so providers know what value to use and practitioners can reliably depend on the value across providers.

Definition of done

• [x] Rationalize vendor-neutral, cross-cloud naming
• [x] Complete spec template and include naming (code name, display name), constraints, guidelines, compatibility with major providers etc.

Want this clarification in FOCUS 1.0 GA?

Give it a 👍 below ↴

If you can discuss and help finalize the change, add yourself as an assignee ↗

Comments are welcome and encouraged!

[ijurica]

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?

[marc-perreaut]

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).

[flanakin]

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.

[flanakin]

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?

[marc-perreaut]

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.

[jpradocueva]

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.