Feedback on EI-CTS-1.0-csd01

Hello,Â

While I have not participated in this discussionÂbefore, I work part of a group developing a TE platformÂwith a focus on energy resilience. We are following the CTS updates to ensure conformance.

I am aware that this feedback is coming in late, but I've decided to send it nonetheless in case it may still be useful.

I am glad to see CTS coming together in a comprehensive way. Congratulations to the technical committee behind CTS. It represents a much-needed step in standardizing the TE markets in a time when TE becomes more relevant every day to a growing audience.

Power vs Energy

In the initial part of the document both power and energy are referred to as acceptable values for a Resource. Given thereâs an ongoing confusion between power and energy, I believe the TC should not promote both in the standard as acceptable. To have any practical TE use energy must always be bound to a unit of time and thus a rate of delivery (power). Whether the power should be levelized or follow an acceptable curve within the interval as defined in [EMIX] thatâs beyond the scope. The resource that an actor tenders, transacts, delivers, and settles is energy. Power is just an attribute of that energy tender, contract, and delivery.

[Lines 11,16,17,229]

Market Rules Enforcement

Until the standard covers the facets, operation, and information models of an auditor and enforcer actor, the free interoperation of distinct conforming implementation is going to be hindered. It is hard to imagine a vendor accepting a standard-conforming actor with a distinct implementation to trade freely, knowing it can introduce malicious behavior and that thereâs no standard way to inhibit it that the actor would oblige by.

[Lines 195]

ÂÂ

Market vs Marketplace Context

When discussing [EMIX] and further down when discussing the Market facet market context/characteristics are used inconsistently introducing confusion. To exemplify contrast the definition in Table 2-1, with the definition in Table 3-4 and Table 3-5, and section 6.1. I suggest clarifying what definition is the one adopted by CTS and the distinctions with [EMIX] and [EI].

The order of models in section 6 implies that an actor first requests the Market Context and then the Marketplace Context. In the real world, this would be in reverse.

[Lines 249, 282,367, 465, 492]

Market-Product-Resource Relationship

In a few places in the standard, there is vagueness that can be misinterpreted around the cardinality relationship between a market, product, and resource.

[Lines 249 Table 2-1]

Matching Engine Privacy

I believe the matching algorithm (or at least the type) in a market should be public information to the participants not hidden. It provides trust in the market and allows participants to develop trading strategies accordingly.

[Lines 273]

Transactions vs Contract

The standard implies a one-to-one relationship between transaction and contract. In practice, I believe it is more appropriate to have a one-to-many relationship between transactions and contracts. Each party of a transaction will receive its own distinct contract (the counterparty may not be public to each other). Also, for the market to match an integral tender, t may have to match with multiple counterparties tenders to create a transaction.

[Lines 282, 318, 379]

Product Warrants

CTS provides a warning on segmentation and shallow markets risk with the excessive use of product warrants. I believe an actor can achieve the same behavior by extending the tender model within the same market with additional attributes that specify a preference. Therefore, the market matching engine can try to satisfy that preference without the risk of creating a shallow market.

[Lines 348,355]

Tender Facet - Update

The standard does not call for an Update Tender payload. There are multiple practical instances where an actor would have to update an uncommitted tender.Â The alternative of canceling and resubmitting, introduces more implementation complexity, excessive communication, and dead time of potential missed transactions.Â

[Lines 545]

Tender Facet â Distribute Tender

I cannot find a practical use or understand the need for EiDistributeTender payload.

[Lines 549]

Tender Facet â Product, Instrument, and Interval

Is not Interval a key aspect of an Instrument instead of a product? (Duration is an aspect of the product).

[Lines 555]

Tender Facet â Payloads Definition

Why is a resourceDesignator required when theÂtender already infers it? Tender implies an instrument. Instrument implies product. Product implies a market. Market implies a resource. If the intent is to identify the market, why not specify the product or market directly?

Why is there a CounterPartyID in the responses for EICreatedTender and EiCanceledTender payload?

[Lines 572]

Transactive State

Transactive state values are not documented in CTS nor [EMIX]. While one can imply the meaning, the boundaries of each state seem vague when analyzed. Is there an implied order too? What state would a delivered and settled tender take? Delivery or publication?Â What about in a market where settlement occurs at the time of the transaction before delivery?
Having the same transactive state map over both tenders and transaction is a stretch when taking the individual values.Â This dual-use also becomes a source of conflictual information and implementations intent between a tender transactive state and the transaction transactive state.

[Lines 555, 599]

Transaction Facet

The interaction pattern and payload are confusing. The interaction diagram shows Party and a Counter Party with the Party initiating the EiCreateTransactionPayload().
This seems counterintuitive for a typical scenario, where a market actor would match two parties. For each of their contracts, one is the Party the other CounterParty. The market needs to notify each andÂconfirm the transaction. What is the expected payload of the market sent to the two parties? EiCreateTransactionPayload or EiCreatedTransactionPayload? In what scenario does a Market actor need to expose both? If the latter, who would call EiCreateTransaction?

[Lines 592]

Tender Privacy

The individual tenders and parties are indeed private information. But as with financial markets, there is public information derived from the tenders for each instrument. This should include the top of the book that can be an aggregation of multiple tenders (market price/cheapest sell price and quantity, highest buy price and quantity), market spread, and market depth. Is there any scenario in which TE will want to behave differently? Even if the current market price for an instrument is public it offers no guarantees. For a buy tender to match in both price and quantity (and possibly other aspects) the price will be higher than the market price.

[Lines 592, 745]

Quote Facet

The facet payloads do not seem to provide a way for participants to ask for public market information for an instrument. i.e. What is the market price for 10kW at 11 AM tomorrow? The same information may be publicly distributed on price change, but a new actor that just joined the market should have a way to ask for that quote. What is the intended purpose for Cancel Quote payload?

[Lines 737, 741]

Ticker Facet

The ticker should obfuscate the parties. The model should include for each instrument the last transaction quantity and price, direction of the price change since the previous transaction, price change value.
Any request (or distribution for a ticker) should default to only the last transaction but historic (or time bounded) transactions could be returned for each instrument. The goal of the ticker is informative only. What is the purpose of the Cancel Ticker?

[Lines 744,756]

Security and Privacy

Line 916 refers to encryption of messages using a lower case "should" whilst on line 985 the same encryption of messages is referred to with RFC uppercase MAY. This may inflict contradicting/vague recommendations in terms of message encryption. I suggest you use the same term for the use of encryption. I also believe that encryption, if not an absolute requirement, should be at least referred to with the word SHOULD and RECOMMENDED as defined by RFC2119. The example on line 979 in reference to a distribution system operator does not seem to be related to either security or privacy. Line 988 is using a confusing statement format. Consider rephrasing for clarity "counterparty of the market" to "market as the counterparty".

[Lines 916,985,979,988]

ÂÂ

Minor typos and formatting issues

10	"Is a means", double use of the word including.
249	Inconsistent use of periods on definitions.
668	"involves a includes"
918	ÂUnpaired closing quotes around man-in-the-middle
980	Typo used the word tame instead of the same.
Page 2	Keywords section, RFC2119 is a broken hyperlink.

Hope this helps,

Horia

--
Horia Pop
VP of Technology â Lateral
+1 (650) 313 3117
horia.pop@lateral-inc.comÂ/Âlateral-inc.com

energyinterop-comment message