Opt-in rights, Opt-Out rights, et al. are conditions of the Agreement (and its "sub-class" Program), and as such are outside the scope of this agreement. Constellation, at least, has publicly demonstrated user interfaces to support both opt-in and opt-out.

Energy Interop makes no assumptions about what it is apropriate to say, or what agreements should say, just what can be said.

Standards should also provide consumer choice as an explicit requirements and not subject that to service provider/agreement discretion. It goes back to the reliability of DR programs (not so much of an issue with RTP) where customers tend to consider participation if they're given choice. This should not be closed without agreement from the commenter or consensus from the TC.

Assuming that EiConstraint and EiOptout cover what in the IRC model labels as commit or dispatch status (as suggested by Bruce), these attributes can be part of an Enrollment (which I think in EI means part of an agreement) but it can also be overridden when an Offer (in the IRC) is submitted. hence it is not only in the Agreement.

Not clear where the disagreement is, Rish.

Standards cannot provide consumer choice, any more than TCP provides consumer choice if there is only one provider in town. Standardscan support consumer choice, especially when built into an application, or when they enable market rule-makers (PUC, etc.) to open up markets without undue re-casting and re-building.

Agreement maps to the Market Context.

For wholesale, that market context is likely to be each ISO or RTC. They have market rules, and all EI can do is enable them; A communication specification will not define the market rules.

For most retail, the market context is the program, which today is usually some sort of Tariff. Whether they can opt out or not is based on the terms of that tariff. We cannot enforce choice, there, with this specification. We can only enable it. FERC, even, cannot enforce choice there, they can only urge the PUC's to.

If the question is, should we use the same list as in Wholesale, I think that list is up to the VTN and the VTN/VEN agreement. Bruce's lis is a fine one. If the Oregon PUC mandates that the local utilities add "Bad Hair Day" and "Raging against the Machine" as options, then EI should support that (meaning no fixed list).

Perhaps I am being dense, but I am not sure what I am missing here.

For I just need to verify where in the model these attributes can be used when enrolling (i.e. registering in EI) or when submitting an Offer (in EiConstraint and EiOptout).

Toby: I think the issue here is closing the item without sufficiently understanding the underlying rationale of the request. Please see other suggestions that I concur with.

All opt-out messages should include an optional string description which shall possibly be enumerated within the context of a given Agreement or Program

Question: As the EGetProgram (sic) call lets [dumb device-based ESI] ddbe change its ui based upon some key facts, (Your program has 7 levels, level 3 is "normal"), should it also include an optional list of strings?

Of course, my impliemntation of consumer choice would be to invoke

MYODB

I discussed this issue with Bill Cox, Toby, Bruce, and EdK. There is apparently a requirement in the NAESB req docs for an "Opt-In" approach, but Ed Koch did not know the source of that, whether there is really a need, or simply it was a use case discussed that might be useful. OpenADR is the basis for the current Constraint and Opt-Out approach, and the current approach has the blessing of the OpenADR TF (I believe). Bill pointed out that the EiConstraint service actually has both positive (acceptSchedule) and negative (notAcceptSchedule) views of the constraints, but Bill thought adding this positive/negative element to OptOut (or changing the name to something like "tempConstraint") would be problematic.

To the issue of text strings, which are presently covered with the "reason" attribute in the EiOptout class, Bruce didn't like the name "reason" since maybe it didn't express the idea of the project codes that would be passed in this text string (such as the IRC text items mentioned here, i.e., "economic, emergency, must run, not participating, outage run status, override status, participating.") We can change the name if there is a better suggestion that everyone agrees to.

The proposed resolution then is to leave everything as is, and get confirmation from the IRC that this meets their needs.

Planned resolution is to use the constraints from EMIX, align the Ei Constraints (slow moving), and add OptIn in addition to OptOut. Needs careful definition of priority, e.g. Opt-In/Opt-Out beats Constraints, Relationship and conformance for incompatible Contraint In/Out and Opt In/Out must be addressed.

Use WS-Calendar vavailability (EMIX Business Calendar) to define Opt In, Opt Out.
Add a Reason string to Opt Out
Standard strings (as per IRC) plus x-strings

Included in 20110305 model.

Are these addressed and the standard strings used?