D-032 Which of the Deals API's statements bind a party, as obligations no payload shows?

Gap Cited on main and at the tag 1.0-202602.

What the schemas do

Each statement about what a buyer, a seller, or both do, with a deal or with the bid requests it covers, is an obligation of that party, with no schema keyword and no vector.

Options

obligations Chosen
Each statement about what a buyer, a seller, or both do, with a deal or with the bid requests it covers, is an obligation of that party, with no schema keyword and no vector.
informative
Each is guidance, with no conformance content.

Why

These sentences say what the parties do: buyers validate bid requests against the deal and apply its targeting, sellers set auxdata when non-publisher data is paid for, both sides coordinate seat IDs a priori. None can be checked on a deal payload, so each is an obligation of the party it names: the buyer, the seller, or, where both are meant, each implementation.

What we ask the specification to state

Write each party's duties in capitals, and say which side each binds: many say "implementers", which names both.

The specification lines it rests on

Each line is quoted as the record pins it. Expand an item to read the quote.

main

What it isn't, a requirement L62 at 3028ddc
Implementers are strongly encouraged to validate the conditions laid out in this deal with OpenRTB requests to ensure their expectations are being met.
Considerations, a requirement L69 at 3028ddc
The information contained in this API should be used as a guide of what the terms that were agreed to, but they should never be used to bid without validating that information coming from the OpenRTB Bid Request is in line with the terms laid out in this API.
Considerations, a requirement L70 at 3028ddc
In other words, buyers should ALWAYS apply targeting matching the terms outlined in any deal on their side.
Considerations, a requirement L70 at 3028ddc
For example, if a deal is struck for US only inventory, buyers should include that targeting in their DSP when trafficking the campaign.
Considerations, a requirement L71 at 3028ddc
If bid requests continually do not match the expectations laid out in the API, a conversation should be had between the buyer and seller to continue negotiations offline.
Considerations, a requirement L72 at 3028ddc
Deal IDs receiving requests without that information should be used rarely and closely monitored.
Object: Deal, a requirement L86 at 3028ddc
The person inputting the deal into the origin system should consider that when setting up the deal.
Object: Deal, a requirement L92 at 3028ddc
IDs of seats and knowledge of the buyer's customers to which they refer must be coordinated between bidders and the exchange a priori.
Object: Deal, a requirement L93 at 3028ddc
IDs of seats and knowledge of the buyer's customers to which they refer must be coordinated between bidders and the exchange a priori.
Object: Inventory, a requirement L128 at 3028ddc
If used, the values in this attribute must contain the same value used in transactions (i.e. OpenRTB bid requests) in the field specified by the SSP/exchange.
Matching Bid Requests to Deals, a requirement L187 at 3028ddc
Conversations between implementers should be had around what attributes, if any, may be subject to change after the deal has gone live.
Matching Bid Requests to Deals, a requirement L191 at 3028ddc
Implementers are strongly encouraged to discuss where targeting criteria will be set.
Matching Bid Requests to Deals, a requirement L191 at 3028ddc
In instances where additional targeting will be applied in the receiving system, implementers should discuss potential implicaitons to delivery if sources of targeting may differ.
Authorization, a requirement L196 at 3028ddc
Supply Chain validation should always be done using Object: Supply Chain from OpenRTB.
Authorization, a requirement L196 at 3028ddc
If this information is unavailable, implementers should proceed with extreme caution with the understanding that there is no mechanism to know if a given path is authorized to sell the inventory.
Auxiliary Data, a requirement L213 at 3028ddc
auxdata should be used whenever any non-publisher data is expected to be part of a given deal.
Auxiliary Data, a requirement L213 at 3028ddc
While the non-publisher data entities are not named, if any company is being paid for their data and/or optimization, this value should indicate the presence of non-publisher data.
Auxiliary Data, a requirement L215 at 3028ddc
For example, a deal starts with some additional data and expects the list of data and/or optimization services to be added or updated as the deal is in flight should use a value of 2.
Publisher Count, a requirement L222 at 3028ddc
Intermediaries should be identified using Supply Chain Validation from OpenRTB requests.
Dynamic Inventory, a requirement L227 at 3028ddc
Implementers are strongly encouraged to communicate and discuss the specifics of any and all inventory updates to ensure expectations are met.

Tag 1.0-202602

What it isn't, a requirement L62 at 938a5d1
Implementers are strongly encouraged to validate the conditions laid out in this deal with OpenRTB requests to ensure their expectations are being met.
Considerations, a requirement L69 at 938a5d1
The information contained in this API should be used as a guide of what the terms that were agreed to, but they should never be used to bid without validating that information coming from the OpenRTB Bid Request is in line with the terms laid out in this API.
Considerations, a requirement L70 at 938a5d1
In other words, buyers should ALWAYS apply targeting matching the terms outlined in any deal on their side.
Considerations, a requirement L70 at 938a5d1
For example, if a deal is struck for US only inventory, buyers should include that targeting in their DSP when trafficking the campaign.
Considerations, a requirement L71 at 938a5d1
If bid requests continually do not match the expectations laid out in the API, a conversation should be had between the buyer and seller to continue negotiations offline.
Considerations, a requirement L72 at 938a5d1
Deal IDs receiving requests without that information should be used rarely and closely monitored.
Object: Deal, a requirement L86 at 938a5d1
The person inputting the deal into the origin system should consider that when setting up the deal.
Object: Deal, a requirement L92 at 938a5d1
IDs of seats and knowledge of the buyer's customers to which they refer must be coordinated between bidders and the exchange a priori.
Object: Deal, a requirement L93 at 938a5d1
IDs of seats and knowledge of the buyer's customers to which they refer must be coordinated between bidders and the exchange a priori.
Object: Inventory, a requirement L128 at 938a5d1
If used, the values in this attribute must contain the same value used in transactions (i.e. OpenRTB bid requests) in the field specified by the SSP/exchange.
Matching Bid Requests to Deals, a requirement L187 at 938a5d1
Conversations between implementers should be had around what attributes, if any, may be subject to change after the deal has gone live.
Matching Bid Requests to Deals, a requirement L191 at 938a5d1
Implementers are strongly encouraged to discuss where targeting criteria will be set.
Matching Bid Requests to Deals, a requirement L191 at 938a5d1
In instances where additional targeting will be applied in the receiving system, implementers should discuss potential implicaitons to delivery if sources of targeting may differ.
Authorization, a requirement L196 at 938a5d1
Supply Chain validation should always be done using Object: Supply Chain from OpenRTB.
Authorization, a requirement L196 at 938a5d1
If this information is unavailable, implementers should proceed with extreme caution with the understanding that there is no mechanism to know if a given path is authorized to sell the inventory.
Auxiliary Data, a requirement L213 at 938a5d1
auxdata should be used whenever any non-publisher data is expected to be part of a given deal.
Auxiliary Data, a requirement L213 at 938a5d1
While the non-publisher data entities are not named, if any company is being paid for their data and/or optimization, this value should indicate the presence of non-publisher data.
Auxiliary Data, a requirement L215 at 938a5d1
For example, a deal starts with some additional data and expects the list of data and/or optimization services to be added or updated as the deal is in flight should use a value of 2.
Publisher Count, a requirement L222 at 938a5d1
Intermediaries should be identified using Supply Chain Validation from OpenRTB requests.
Dynamic Inventory, a requirement L227 at 938a5d1
Implementers are strongly encouraged to communicate and discuss the specifics of any and all inventory updates to ensure expectations are met.

The record's YAML file