Exhibit 99.225
Congestion Management Reform - July 11, 2000 Proposal
Stakeholder Comment Template
OVERALL COMMENTS
1. Which fundamental market design features and principles identified in the
proposal should be kept? Why?
2. Which fundamental market design features and principles identified in the
proposal should be removed? Why?
The ISO is to be congratulated for its commitment to minimize its role in
the forward markets. The comments here in are intended to assist the ISO
live up to this commitment.
The ISO should not expand the number of markets that it runs to meet
reliability and efficiency goals, nor should it advance the time at which
it runs markets. Rather, it should provide the information and products
that the SCs would need to meet these needs. In this vein, the ISO should
remove the 2 day-ahead LRS market from the CMR proposal. This 2-day head
market will not only insert a new ISO run market, it will distort the SC's
existing day-ahead energy markets in the process.
The ISO's scheduling of LRS energy in the two day ahead market will likely
satisfy the associated nomogram and eliminate any congestion into the
affected area. This will seriously reduce the value of FTRs into the area.
Only when ISO mis-forecasts area loads will ISO not procure enough energy
to satisfy the nomogram thereby resulting in a value to the associated
FTRs. This puts FTR buyers in the position of speculating on the ISO's
ability to forecast demand, which is not appropriate.
LRS should be recognized as a reliability service like other Ancillary
Services, and combined into the A/S rational buyer program. The LRS market
should be moved to the day-ahead and treated similar to Replacement
Reserves as will be expanded upon below, and the FTRs should be nomogram
FTRs which can be used by ESPs/SCs that are supplying LRA demand to hedge
against import limitations.
The recallable transmission rights (RTRs) could be sold in an annual
auction as for FTRs, and should be tradable in a secondary market as for
FTRs. Revenues from the sale of the RTRs could be handled as for FTRs.
The ISO has dismissed with virtually no justification or real explanation
a physical rights approach and use-or-lose FTRs. These features would also
help reduce the role of the ISO in forward markets without compromising
reliability and should be considered for incorporation.
Stakeholder Comment Template
SECTION NUMBER AND TOPIC PAGE REFERENCE IN PROPOSAL
- ------------------------ --------------------------
DETAILED COMMENTS
1. INTRODUCTION.....................................................................1
General Comments:
2. THE CONGESTION MANAGEMENT REFORM PROCESS.........................................3
General Comments
3. CONGESTION MANAGEMENT REFORM: BACKGROUND AND MOTIVATION..........................6
General Comments:
4. CONGESTION MANAGEMENT REFORM DESIGN FRAMEWORK AND CRITERIA......................14
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
4.1 DESIGN FRAMEWORK................................................................15
Features that should be kept; Why:
Keep the emphasis on decentralized decision making in the markets. This
allows the markets to innovate to meet the needs of suppliers and
consumers. A free market with competitive pressures will be much more
innovative in developing new products and services than a bureaucracy.
Market separation is the foundation that allows decentralized decision
making and competition between SCs.
Consistency between real time operations and ISO support of forward
markets is essential. If CONG is retained (I.e. no shift to a physical
market) it should include all nomograms or other restraints on real time
operations.
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
4.1.1 REAFFIRMATION OF THE ORIGINAL CALIFORNIA DESIGN PRINCIPLES......................15
Features that should be kept; Why: Both that are listed.
Features that should be removed or modified; Why and how:
Features that should be added; Why and how: Affirmative declaration of
intent to minimize role of ISO in forward markets, and intent to take
actions that would actively encourage secondary markets and self
Page 2 of 19
Stakeholder Comment Template
SECTION NUMBER AND TOPIC PAGE REFERENCE IN PROPOSAL
- ------------------------ --------------------------
provision of LRS and ancillary services. An escalating surcharge on
purchases in the ISO market to reduce the GMC is a possible approach.
4.1.2 FUNCTIONAL UNBUNDLING...........................................................16
Features that should be kept; Why: Separation of transmission and energy
markets.
Features that should be removed or modified; Why and how:
Features that should be added; Why and how: Strengthen incentives and
opportunities for private parties to construct new transmission. Support
such efforts positively at FERC and elsewhere. Get the missing A/s markets
jump started; e.g. reactive poer, black start, etc.
4.1.3 DECENTRALIZED DECISION MAKING...................................................17
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how: Inter-SC adjustment bids
(assuming again, that CONG is kept and a physical rights model is not
adopted.)
4.1.4 THE ORIGINAL DESIGN PRINCIPLES AS THE BASIS FOR CONGESTION MANAGEMENT REFORM....17
Features that should be kept; Why: Maintain the present system that does
not have ISO produce a central dispatch in the forward markets. LMP can be
obtained through a flowgate and shift factor approach as is currently
proposed.
Features that should be removed or modified; Why and how: The alternative
Design Approach which would adopt point-to-point approach to energy and
FTR pricing should not be considered. The shift factor approach and FTRs
that do not obligate the holder to schedule is preferred. The ISO should
not be in the business of forward sale of counter-flows that based on the
assumption that an FTR holder will always be obligated to schedule its use
or face financial risks.
Features that should be added; Why and how:
4.2 DESIGN CRITERIA.................................................................19
Features that should be kept; Why: Keep the criteria listed. In
particular, reliance on market incentives rather than rules that need to
be policed and enforced with penalties, etc.
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
4.2.1 RELIABLE OPERATIONS -...........................................................19
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Page 3 of 19
Stakeholder Comment Template
SECTION NUMBER AND TOPIC PAGE REFERENCE IN PROPOSAL
- ------------------------ --------------------------
Features that should be added; Why and how:
4.2.2 ECONOMIC EFFICIENCY -...........................................................19
Features that should be kept; Why: A statement that the ISO's role in
efficiency does not extend to central dispatch in forward markets. Real
time is sufficient to sweep up any gains not realized in the private
market through private transactions where superior efficiency is expected
as compared to central command and control.
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
4.2.3 MARKET EFFICIENCY -.............................................................19
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
4.2.4 INSTITUTIONAL FACTORS...........................................................20
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
4.2.5 EVALUATION CRITERIA ADOPTED AT THE MAY 10-11 STAKEHOLDER MEETING:...............20
Features that should be kept; Why: All. However, SH 8 should not extend to
intrusion into private markets and commercially sensitive data.
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
4.3 CURRENT IMPEDIMENTS TO COMPETITIVE MARKET DEVELOPMENT...........................21
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
5. REAL-TIME OPERATIONAL REQUIREMENTS..............................................22
General Comments: Bringing real time locational pricing in line with
forward markets is an important step in the right direction.
Page 4 of 19
Stakeholder Comment Template
SECTION NUMBER AND TOPIC PAGE REFERENCE IN PROPOSAL
- ------------------------ --------------------------
All operating rules and procedures, including operating nomograms, should
be made available.
Clarify the proposal regarding use of BEEP. It is stated that the
simplified commercial model would be integrated with a more traditional
EMS using an OPF for real time operation. The 7/11 document still talks at
some points in terms of BEEP.
Provide some concrete examples to show how the ten-minute market would
work absent the target price mechanism.
6.4 What is meant by scheduling at the node level as they do today. Scheduling
today is not at the node level for demand.
Will west of river and east of river nomograms be sold? SCIT nomogram? Four
corners?
Take out the language saying CONG will not produce resource specific final
schedules.
How would the rule about reverting to the original schedules work? Suppose
congestion increases on one path and decreases on another? How will "increase"
be measured, dollar value? How will reservation for A/S be factored in?
6.5 There is no reason to require an LRS schedule to be matched in the LRA with
demand. Concerns about reverse congestion are misplaced. The PX is large enough
that this will not be a problem, and inter-SC trades also act to reduce any
concerns in this regard. If an SC makes a stupid mistake and matches LRS gen.
with external load across the COI interface and is dec'd as a result, it should
be penalized as discussed for failure to schedule LRS energy. The likelihood of
actually having this occur is so small, it should not be allowed to cause
imposition of unnecessary rules on the market that could reduce efficiency in
the market or constrain trade.
6.6 As noted above, the recallable rights should be sold forward. Any RFTRs and
any FTRs not scheduled in the DA market would then be sold in the ISO CONG
recallable market. Per the ISO proposal, unused SABs could be used in this
market. FTRs would be use or lose in the HA market instead of the DA market.
Recall would be based on a cost minimization approach.
7. THE LONG-FORWARD MARKET.........................................................35
Features that should be kept; Why: None.
Features that should be removed or modified; Why and how: All.
Features that should be added; Why and how: It should be shifted into the
day-ahead market. The ISO should then only purchase the amount needed and
not self provided.
7.1 LPA DEFINITION AND CREATION.....................................................35
Features that should be kept; Why:
Features that should be removed or modified; Why and how: There does not
appear to be any reason to have a shift factor correlation criteria if the
shift factors are calculated using the simplified
Page 5 of 19
Stakeholder Comment Template
SECTION NUMBER AND TOPIC PAGE REFERENCE IN PROPOSAL
- ------------------------ --------------------------
commercial model and there are no loops. Absent loops all resources in an
LPA or zone must have identical shift factors, specifically, 1.0.
Features that should be added; Why and how:
7.1.1 INTRODUCTION....................................................................35
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
7.1.2 LPA DEFINITION..................................................................35
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
7.1.2.1 DEFINING LPAS USING NOMOGRAMS...................................................35
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
7.1.3 CREATING NEW LPAS...............................................................35
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
7.1.3.1 LPA-CREATION CRITERIA...........................................................35
Features that should be kept; Why: Please explain and justify use of
equivalents for the external WSCC grid. Explain why this is necessary.
Please explain in term of present scheduling rights.
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
7.1.4 OTHER OPTIONS CONSIDERED........................................................36
Features that should be kept; Why:
Page 6 of 19
Stakeholder Comment Template
SECTION NUMBER AND TOPIC PAGE REFERENCE IN PROPOSAL
- ------------------------ --------------------------
Reject the joint optimization of transmission allocation and dispatch of
energy. The joint optimization would effectively take control of the
day-ahead and hour ahead energy markets from the SCs and give it to the
ISO. This is counter to the goal of fostering decentralized decision
making.
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
7.1.5 OPEN ISSUES.....................................................................38
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
7.2 FIRM TRANSMISSION RIGHTS.......................................................39
Features that should be kept; Why:
Features that should be removed or modified; Why and how: 3 years for 50%
is too long for the initial sale.
Features that should be added; Why and how:
7.2.1 BACKGROUND ON CURRENT FTR PRODUCT...............................................39
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Modify the priority of allocation of day-ahead transmission capacity to
reflect the actual contracts rights. Not all ETCs give higher priority
access to the ETC holder as compared to other who are using NFU. ISO
should correct its software to accurately mirror the contract provisions.
FTR holders are using NFU capacity. Those ETCs that have the same priority
as other NFU should be curtailed pro-rata with FTR holders.
Features that should be added; Why and how:
7.2.2.1 100% RELEASE....................................................................40
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
7.2.2.2 FTR TERM AND AUCTION............................................................40
Features that should be kept; Why:
Page 7 of 19
Stakeholder Comment Template
SECTION NUMBER AND TOPIC PAGE REFERENCE IN PROPOSAL
- ------------------------ --------------------------
Features that should be removed or modified; Why and how:
The ISO's proposal for 3 year FTR capacity and possible yearly updates of
LPAs increases the uncertainty surrounding the value of FTRs. In
particular, the ISO's description of how it will define and allocate new
FTRs to holders of FTRs when the LPAs are changes is fuzzy. To eliminate
the uncertainty and improve the ability of participants to forecast the
value of FTRs, ISO should make the term of the FTRs 1 year and only update
LPAs yearly.
Features that should be added; Why and how:
7.2.3 IMPACT OF AND ISSUES REGARDING PROPOSED CHANGES.................................40
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
7.2.3.1 FTRS UNDER A LOOPED NETWORK MODEL...............................................40
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
7.2.3.2 FTR MONITORING..................................................................41
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
7.2.3.3 FTRS AND LPA CHANGES............................................................41
Features that should be kept; Why:
Features that should be removed or modified;
Why and how: The proposed methodology will increase the uncertainty that
participants face in valuing FTRs. ISO should eliminate the uncertainty by
making the term of FTRs and changes to LPAs compatible at 1 year.
Features that should be added; Why and how:
7.2.4 OTHER OPTIONS CONSIDERED........................................................43
Features that should be kept; Why:
Page 8 of 19
Stakeholder Comment Template
SECTION NUMBER AND TOPIC PAGE REFERENCE IN PROPOSAL
- ------------------------ --------------------------
ISO should keep the definition of FTRs as capacity on the transmission
that forms zonal interfaces and the right to collect usage charges on
those interfaces. ISO should not move to point to point FTRs as considered
in one of the rejected alternatives. Defining FTRs as capacity on
interzonal transmission interfaces allows participants to buy FTRs that
give them the option to schedule flows and/or collect congestion usage
charges. They will not face the possibility of paying congestion fees if
they do not schedule the use of their FTRs. This latter possibility would
make it much more difficult to determine the value that a participant
should bid for a 1 year (or 3 year) FTR. A participant is unlikely to want
to schedule a flow on the FTR capacity in each hour for 365 days a year.
The point to point FTR would require the participant to evaluate the
potential risk it would face when it does not schedule a flow in some
hours of the year.
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
7.2.5 OPEN ISSUES.....................................................................43
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
Preference among stated options (Primary FTR auction revenues and Usage
Charge revenues allocated to PTOs and FTR holders vs. path-specific
transmission upgrade fund vs. loads within the congested LPA):
Revenues should be allocated to PTOs and FTR holders.
7.3 LOCAL RELIABILITY SERVICE.......................................................44
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
ISO should sell FTRs directly on the nomogram constraints. For example,
suppose that ISO had a nomogram that specified minimum in-area generation
as a function of load
Page 9 of 19
Stakeholder Comment Template
SECTION NUMBER AND TOPIC PAGE REFERENCE IN PROPOSAL
- ------------------------ --------------------------
[DIAGRAM]
ISO could sell the capacity on the various segments of the nomogram. This
would allow the participant to schedule in-area load and schedule in-area
generation that would meet its share of the nomogram based requirement.
That is, the SCs could determine their share of locational energy
requirements that result from the nomograms and incorporate them in their
energy schedules.
ISO could incorporate the nomogram constraints in CONG. The dual
information would provide the marginal value of the various segments of
the nomogram constraints. That is CONG could price the nomograms. As a
result, ISO could pay the nomogram FTR owners the "usage charge"
associated with the nomogram thereby providing the FTR owner a financial
hedge for the cost of enforcing the nomogram. It would also enable one SC
to schedule more than its share of the locational energy requirement which
would then be priced by CONG and sold to another SC. This would be
analogous to the counterflows that CONG currently trades between SCs.
ISO could also provide information on the capacity requirements in the
location that must be available to meet N-1 contingencies. The SCs could
then self-schedule their share of the locational capacity requirements.
Any shortfall in scheduled capacity from an SC not self-providing could be
procured by ISO as an ancillary service. This should be integrated in the
ISO's existing rational buyer A/S mechanism to avoid the pitfalls that
resulted when ISO ran sequential A/S markets. If the SCs energy
Page 10 of 19
Stakeholder Comment Template
SECTION NUMBER AND TOPIC PAGE REFERENCE IN PROPOSAL
- ------------------------ --------------------------
schedules in the area do not meet the ISO's forecast requirements, ISO
could procure more capacity in the area which it could dispatch in
real-time if its forecast proves correct. This is analogous to the ISO's
purchasing replacement reserves when the SCs' energy schedules fall short
of the ISO's load forecast.
In general, ISO should rely on the markets rather than introduce new ISO
run markets that can distort the existing energy and A/S markets.
ISO could place caps on energy bids and capacity bids for resources
in-area that have market power and can be used to meet the nomogram
constraints. These bids could be made available to all SCs who would then
be free to arrange purchases from these resources in their IPSs.
Features that should be added; Why and how:
7.3.1 INTRODUCTION....................................................................44
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
7.3.2 OPERATIONAL ASPECTS OF SATISFYING LOCAL RELIABILITY REQUIREMENTS................44
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
7.3.3 THE EXISTING RMR APPROACH.......................................................45
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Replace the RMR approach with the LRA/nomogram approach. However, the ISO
should sell FTRs directly on the nomogram and provide the SCs with the
information that they need to schedule sufficient in-area generation and
capacity to meet the requirements for their in-area load.
Features that should be added; Why and how:
7.3.4 ALTERNATIVE OPTIONS FOR SATISFYING LOCAL RELIABILITY REQUIREMENTS...............45
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
Page 11 of 19
Stakeholder Comment Template
SECTION NUMBER AND TOPIC PAGE REFERENCE IN PROPOSAL
- ------------------------ --------------------------
Preference among stated options (Existing RMR Approach vs. Two-Day-Ahead
LRS Auction vs. LRS Energy Payment Only):
None of these. Sell FTRs on the nomograms and provide the SCs with the
ability to schedule to meet the nomograms (energy and capacity). Enhance
CONG to include the nomogram constraints, price the nomogram constraints
and sell trades or nomogram "counterflows" between SCs.
Preference among stated options (LRS bid cap based on incremental costs of
a new generator vs. variable costs of highest-cost resource within the
LRA):
7.3.5 OPEN ISSUES.....................................................................51
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
Preference among stated options (LRS costs allocated to PTOs, Loads within
the LRA, Loads within a larger area):
With the proposal above, there would be much less LRS costs to allocate
since SCs would have the information needed to meet their share of the
requirements. Any SC that does not schedule sufficient energy would be
allocated a share of the additional capacity that the ISO purchased. ISO
would purchase capacity as an A/S for any SC that does not self-provide
its share of the capacity requirement. The cost of this would be allocated
to the SC.
Preference among stated options (Minimum reliability (MR) energy is
required to be scheduled in DA market vs. MR energy procured through
CONG):
Preference among stated options (Energy bids for unloaded MR capacity
capped vs. receives applicable real-time energy price):
Preference among stated options (Bid caps expire at the end of a sunset
period?):
Preference among stated options (Bid caps escalated over time?):
8. THE DAY- AND HOUR -- AHEAD MARKET....................................................51
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
8.1 DAY-AHEAD CONGESTION MANAGEMENT.................................................51
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Page 12 of 19
Stakeholder Comment Template
SECTION NUMBER AND TOPIC PAGE REFERENCE IN PROPOSAL
- ------------------------ --------------------------
Features that should be added; Why and how:
8.1.1 INTRODUCTION....................................................................51
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
8.1.2 SIMILARITIES WITH THE EXISTING DA CM APPROACH...................................51
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
ETCs should not be given higher priority access to transmission than FTRs
if the contract calls for pro rata access. ISO should modify congestion
management to accurately track contracts and not give higher priority to
ETCs than FTRs when not required by contract.
Features that should be added; Why and how:
8.1.3 NEW FEATURES OF CONGESTION MANAGEMENT...........................................52
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
ISO should not run 2-day-ahead market to procure LRS and require it be
scheduled by SCs in day-ahead. Rather, ISO should sell FTRs on nomograms,
include nomogram constraints in CONG thereby providing the SCs with the
information and tools to schedule LRS energy in their own markets as
described in the previous comments.
Features that should be added; Why and how:
8.1.4 THE COMMERCIAL MODEL............................................................53
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
8.1.5 NETWORK REPRESENTATION..........................................................53
Features that should be kept; Why:
The simplified commercial model is an important feature that will
contribute to vital forward energy markets run by the SCs. It should be
kept.
Features that should be removed or modified; Why and how:
Page 13 of 19
Stakeholder Comment Template
SECTION NUMBER AND TOPIC PAGE REFERENCE IN PROPOSAL
- ------------------------ --------------------------
Features that should be added; Why and how:
8.1.6 THE MODELED CONSTRAINTS.........................................................54
Features that should be kept; Why:
Keep the market separation constraints. They are necessary to allow the
SCs to run forward energy markets in the day-ahead and hour-ahead. Without
the market separation constraints, ISO will effectively take control of
those markets. This would squelch competition between SCs and innovation.
Features that should be removed or modified; Why and how:
The nomogram constraints should be included in CONG as ISO has described.
However, the ISO should also price the nomogram constraints and set
marginal usage charges on these constraints.
Features that should be added; Why and how:
8.1.6.1 OTHER OPTIONS CONSIDERED........................................................56
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Voluntary relaxation should not be allowed. If ISO does decide to allow
it, ISO should not simply give the SCs the option of having their
adjustment bids placed in a common pool or not. ISO should let each SC
specify the other SCs with whom it is willing to trade.
Features that should be added; Why and how:
8.1.7 PRICING (INCLUDING COST ALLOCATION).............................................56
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
8.1.8 OPEN ISSUES.....................................................................57
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
8.1.9 OTHER OPTIONS CONSIDERED........................................................58
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Page 14 of 19
Stakeholder Comment Template
SECTION NUMBER AND TOPIC PAGE REFERENCE IN PROPOSAL
- ------------------------ --------------------------
Features that should be added; Why and how:
8.2 HOUR-AHEAD CONGESTION MANAGEMENT AND DAY-OF LRS.................................59
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
8.2.1 HA CM...........................................................................59
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
8.2.2 DAY-OF LRS......................................................................59
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
8.2.3 OPEN ISSUES.....................................................................59
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
8.3 ANCILLARY SERVICES IN CONGESTION MANAGEMENT.....................................59
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
8.3.1 BACKGROUND......................................................................60
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
8.3.2 AN ALTERNATIVE APPROACH.........................................................60
Page 15 of 19
Stakeholder Comment Template
SECTION NUMBER AND TOPIC PAGE REFERENCE IN PROPOSAL
- ------------------------ --------------------------
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
8.3.3 OTHER OPTIONS CONSIDERED........................................................60
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
8.4 RECALLABLE TRANSMISSION.........................................................62
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
8.4.1 OTHER OPTIONS CONSIDERED........................................................64
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
9. THE REAL TIME MARKET............................................................65
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
9.1 NETWORK REPRESENTATION..........................................................65
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
9.2 IMBALANCE ENERGY PROCUREMENT AND CONGESTION MANAGEMENT..........................65
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Page 16 of 19
Stakeholder Comment Template
SECTION NUMBER AND TOPIC PAGE REFERENCE IN PROPOSAL
- ------------------------ --------------------------
Features that should be added; Why and how:
9.3 PRICING AND COST ALLOCATION.....................................................68
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
10. ECONOMIC SIGNALS, REVENUE ALLOCATION, AND COST OBLIGATION.......................71
10.1 INTRODUCTION....................................................................71
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
10.2 SUMMARY OF PRICING AND ALLOCATION OF COSTS AND REVENUES.........................73
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
10.3 ECONOMIC SIGNALS IN THE PROPOSED PRICING AND COST ALLOCATION METHODS............74
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
10.3.1 FEASIBILITY OF SCHEDULES........................................................74
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
10.3.2 LOCATIONAL PRICE SIGNALS........................................................74
Features that should be kept; Why:
Features that should be removed or modified; Why and how: The 2-day ahead
LRS market does not provide locational price signals to loads in the LPA
upon which the loads can act. The ISO procures LRS based on its forecast
of loads in the LRA. If the ISO purchases of LRS cause the price of energy
to the loads in the LPA to rise, a load may decide to curtail consumption.
How would ISO take this into
Page 17 of 19
Stakeholder Comment Template
SECTION NUMBER AND TOPIC PAGE REFERENCE IN PROPOSAL
- ------------------------ --------------------------
account? Is ISO going to try to forecast the final price seen by each SCs'
loads and the price elasticity of the loads in producing its load
forecast? This seems to be very problematical. It seems likely that the 2
day ahead LRS market will significantly blunt the price signals to price
sensitive loads.
Features that should be added; Why and how:
10.3.3 UNRESOLVED ISSUES...............................................................76
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
10.4. LINKAGES BETWEEN CONGESTION MANAGEMENT REFORM, LONG-TERM GRID PLANNING,
AND NEW GENERATION INTER-CONNECTION POLICY......................................76
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
10.4.1 LONG-TERM GRID PLANNING.........................................................77
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
10.4.2 NEW-GENERATOR INTERCONNECTION POLICY............................................78
Features that should be kept; Why:
Features that should be removed or modified; Why and how:
Features that should be added; Why and how:
11. FERC'S ORDER 2000...............................................................80
11.1 ORDER NO. 2000 AND CONGESTION MANAGEMENT........................................80
Overall Comments:
11.2 ORDER NO. 2000 AND INTERREGIONAL COORDINATION...................................81
Overall Comments:
11.3 ORDER NO. 2000 AND THE RECOMMENDATION PACKAGE...................................82
Overall Comments:
Page 18 of 19
Stakeholder Comment Template
SECTION NUMBER AND TOPIC PAGE REFERENCE IN PROPOSAL
- ------------------------ --------------------------
12. CONCLUSION......................................................................83
Overall Comments:
APPENDIX A - TERMINOLOGY AND ACRONYMS
Definitions that should be modified; Why and how:
Definitions that should be added; Why and suggested definitions:
APPENDIX B - LOCATIONAL PRICE DISPERSION STUDY
General Comments:
Page 19 of 19