Demand Response – ERCOT discussion items Demand Response Taskforce – 12/18/07

Short term options – what do folks have to bring to the table? Options – Short Term Short term options – what do folks have to bring to the table? TXU ES Others?

Discussion – Short term options DRAFT Process for ERCOT based upon TXU ES’s proposal for short term Capacity alert event occurs. REP would provide a list of ESI IDs and the global DR program they were signed up for When another event occurs, REP provides a new list. Suggested cap – 10,000 ESI IDs ERCOT wide (approx 10 MW) Allows the market to step into the process. As the market steps into the program, could report back to TAC? On the volumes to understand when the market will need to implement the long term solutions. May end up going into allocation / lotto . ERCOT compares the list to Lodestar and Siebel and communicates back to the REP any ESI IDs for which they are not the current Rep of Record (ROR). ESI IDs that are not currently setup to be settled on the global DR program. Example – REP sends a list of 20 ESI IDs, ERCOT checks Lodestar– they are the ROR for 15 –those should be shown by Initial settlement. ERCOT checks Siebel for in-flight service orders (SWI / MVI / MVO), and checks currently filed DEV and IAS issues. 3 ESI IDs have orders in flight – should be shown by Final settlement if the REP becomes the ROR. 2 ESI IDs do not have orders in flight – ERCOT would communicate back to REP. REP may want to file DEV – following market timelines – should be shown by True Up settlement if the REP becomes the ROR. Data Aggregation process would reflect the load reduction based upon the ESI ID list and the global DR program assignment. Market continues to work on long term options – this is the bridge

Long term options / what needs to be looked at? Market continue working on automated/transactional ‘flip’ process Make DR profile ID private – when volumes are larger? Other options? Questions Who owns the responsibility to change the profile? Old or New CR requests from TDSP (using MarkeTrak)? TSDP changes based on order completion? ERCOT requests from TDSP (using MarkeTrak)? Assumptions DR Profile ID is public TDSP maintaining and providing profile on existing TX SET transactions in the profile ID segment. Profile should not revert until order effectuates so that if the order is cancelled, the DR profile remains.

Draft flow -- Registering a DR Program Questions: What are the program characteristics? What are the validations of the program at ERCOT?

Draft flow -- Registering an ESI ID to a DR Program Questions: 1. To what extent does ERCOT need to validate the ESIID/CR/DR assignment and program specific characteristics ( i.e. Commercial/Residential; demand thresholds; zip codes) prior to the profile code changing? ESIID affiliated to CR? CR affiliated to DR program? 2. Should validations be limited to only the components of the Profile Code? 3. How is effective date for the Profile code change determined? 4. What happens to ESIIDs that have a DR profile and there is a backdated MVI/MVO, Switch, or Inadvertent Gain? Assumptions 1. For DR profile, ESIIDs that are not included in settlements due to REP-DR profile validation, it is the responsibility of the REP to request the profile update. 2. Based on current system design, 814_20s would be forwarded to ALL pending REPs and the current REP. 3. This is not the flow for the ‘flip’ process.

Draft flow – What happens when Switch/MVI effectuates? Assumptions: This represents how ESI IDs are transitioned back to default profile when ROR changes. Based on current systems. TDSP maintaining and providing profile on existing TX SET transactions in the profile ID segment. Profile should not revert until order effectuates so that if the order is cancelled, the demand profile remains. Questions: Who owns the responsibility to request the change to the profile? New CR requests from TDSP (using MarkeTrak)? TSDP changes based on order completion? ERCOT requests from TDSP (using MarkeTrak)? Is there a need to have a transactional trigger to switch the profile? If MVI CR = Current CR – what happens to the current profile assignment?

Draft flow – What happens with a MVO to CSA effectuates? Assumptions: This represents how ESI IDs are transitioned back to default profile when ROR changes. Based on current systems. TDSP maintaining and providing profile on existing TX SET transactions in the profile ID segment. Profile should not revert until order effectuates so that if the order is cancelled, the demand profile remains. Questions: Who owns the responsibility to request the change to the profile? CSA CR requests from TDSP (Using MarkeTrak)? TSDP changes based on order completion? ERCOT requests from TDSP (using MarkeTrak)? Is there a need to have a transactional trigger to switch the profile? If CSA CR = Current CR – what happens to the current profile assignment?

Draft flow – What happens when a MVO effectuates? Assumptions: This represents how ESI IDs are transitioned back to default profile when ROR changes. Based on current systems. TDSP maintaining and providing profile on existing TX SET transactions in the profile ID segment. Profile should not revert until order effectuates so that if the order is cancelled, the demand profile remains. Questions: Who owns the responsibility to request the change to the profile? Old CR requests from TDSP (using MarkeTrak)? TSDP changes based on order completion? ERCOT requests from TDSP (using MarkeTrak)? If default profile not reverted to, when a new CR submits a MVI, they will be settled on the demand profile. Is there a need to have a transactional trigger to switch the profile?

Questions?