Newsroom  Site Map  Contact NERC       




Individual or group.  (30 Responses)
Name  (15 Responses)
Organization  (15 Responses)
Group Name  (15 Responses)
Lead Contact  (15 Responses)
Question 1  (23 Responses)
Question 1 Comments  (30 Responses)
Question 2  (27 Responses)
Question 2 Comments  (30 Responses)
Question 3  (27 Responses)
Question 3 Comments  (30 Responses)
Question 4  (27 Responses)
Question 4 Comments  (30 Responses)
Question 5  (27 Responses)
Question 5 Comments  (30 Responses)
Question 6  (26 Responses)
Question 6 Comments  (30 Responses)
Question 7  (26 Responses)
Question 7 Comments  (30 Responses)
Question 8  (26 Responses)
Question 8 Comments  (30 Responses)
Question 9  (26 Responses)
Question 9 Comments  (30 Responses)
Question 10  (25 Responses)
Question 10 Comments  (30 Responses)
Question 11  (26 Responses)
Question 11 Comments  (30 Responses)
Question 12  (25 Responses)
Question 12 Comments  (30 Responses)
Question 13  (25 Responses)
Question 13 Comments  (30 Responses)
Question 14  (24 Responses)
Question 14 Comments  (30 Responses)
Question 15  (22 Responses)
Question 15 Comments  (30 Responses)
Question 16  (23 Responses)
Question 16 Comments  (30 Responses)
Question 17  (0 Responses)
Question 17 Comments  (30 Responses)
 
Individual
Jon Kapitz
Xcel Energy
 
Agree
 
Agree
Consider including the term “compatible” as part of the description.
Agree
 
Disagree
It is unclear as to whether an entity must still self report in cases where Interchange Coordination is nonfunctional. Do you have a statistic as to how often this occurs? So, if OATI goes down for an hour, must all EI entities self-report?
Agree
However, INT-009 R2 has “or alternate control process” in parentheses. Believe this should be deleted. ACE is a measurement for compliance that may be used for control purposes. It is up to the entity to comply with the remaining NERC standards, including performance. The entity may be able to accomplish that without incorporating the NSI into their control process. The requirement should only state that the term be used in the BA’s ACE, though this may be unnecessary as ACE is defined in other standards.
Agree
 
Disagree
This is predicated on an electronic platform. What occurs if the electronic platform is not available? Is a manual process taken into account? If a manual process had to be implemented, the 1 minute time frame would not be reasonable.
Agree
We agree with specifying the minimum criteria for which AI can be denied; consider adding language similar to INT-010 R4.5 “Any real-time reliability concern related to a specific Arranged Interchange, provided that concern is supported by evidence.”
Disagree
This question implies that the BA can choose to not approve the Reliability Adjustment. What constitutes the ability of a BA to support the magnitude of Interchange?
Agree
 
Agree
 
Agree
 
Disagree
 
Disagree
 
Disagree
 
INT-009 R2 has “or alternate control process” in parentheses. Believe this should be deleted. ACE is a measurement for compliance that may be used for control purposes. It is up to the entity to comply with the remaining NERC standards, including performance. The entity may be able to accomplish that without incorporating the NSI into their control process. The requirement should only state that the term be used in the BA’s ACE, though this may be unecessary as ACE is defined in other standards. INT-011-1 R1.1 refers to a Load Balancing Authority. Should this be Sink Balancing Authority? With respect to requiring an entity to be able to “electronically” perform functions, consider the need to state that is must be compatible with the Interchange Coordination tools. In general: • the standards are wordy and written in a manner that is difficult to understand. • Is there an ability to use a manual process in lieu of an electronic system if the Interchange Coordination tools are not available? If so, do the requirements need to cover this situation?
Group
Functional Model Working Group
Jim Cyrulewski, Chairman
 
Disagree
The Functional Model Working Group (FMWG) does not agree with removing the IA from the NERC standards. The FMWG would like to make clear what is meant with the statement "… assigning those functions to the Sink Balancing Authority directly would not conflict with the functional model" The FMWG has clearly articulated in the Functional Model Report and in the associated Functional Model Technical Report that the Functional Model does not in any way presume to direct the Registration process associated with NERC Reliability Standards. The Functional Model itself identifies independent tasks that can be accomplished by independent entities. The IA is one such set of independent tasks. That set of tasks has been and continues to be a required “function”. The FMWG wants to make clear that the IA function is regarded as a critical reliability function and should not be removed. Regarding registration, the FMWG does not regard registering NERC-registered Balancing Authorities (BA) as IAs to be in conflict with the Functional Model. The FMWG would note that “Each BA may be an IA; but not every IA needs to be a BA.” There is a significant difference between the two ideas. It should be noted that none of the NERC and FERC-approval functional entities are “actual entities” until a corporate entity registers (or is registered) by NERC to comply with the standards written to the respective functions. The SDT misconstrues the issue. The FMWG agrees with the NERC Regions’ default position is that if no entity registers as an IA, then the sink BA will be held responsible for the IA requirements. The lessons learned when NERC was operating under voluntary policies was that if a set of functions can be served independently; ultimately some entity will fill that position. The fact that the IA functions have the potential to be served by a corporate entity that does not need to fill all of the NERC BA requirements indicates the need to separate the tasks from the BAs. That does not mean that in the absence of such a corporate entity, that the BAs (as a default position) cannot be assigned to be compliant with the IA tasks. To return to a blanket assignment of the IA tasks to the BA is to ignore the lessons of the history of NERC. Lastly, there is no issue with requiring BAs to comply with the tasks defined for the IA. The original confusion was/is with the concept that a delegated (non-registered) third-party is providing the IA functions. However, to eliminate the reference to IA and to place the same tasks under the BA does nothing to rectify that issue/non-issue. However, the elimination of IA will mean that in the future when a corporate entity does want to register to do those tasks that entity will by necessity have to be a BA. Thus it can be seen that eliminating IA is not the same as requiring BAs to comply with the IA functions.
Disagree
 
Disagree
 
Disagree
 
Disagree
 
Agree
 
Disagree
 
Disagree
The reliability issue is whether or not the Interchange is approved or denied. The reasoning for that decision is not a reliability issue as much as it is a business issue.
Agree
 
Disagree
.
Disagree
 
Disagree
 
 
Disagree
 
Agree
 
PLEASE NOTE THAT THE FMWG IS SUBMITTING COMMENTS ONLY TO QUESTION 2 The survey form does not provide the option to deselect the agree/disagree entry once it is checked. All other responses should really be NO RESPONSE.
Individual
James Starling
South Carolina Electric and Gas
 
 
 
 
 
 
 
 
 
 
 
 
 
Disagree
SCEG believes the Confirmed Interchange profile is not required to be checked out hourly, but upon changes in schedules
 
 
 
Group
Northeast Power Coordinating Council
Guy Zito
Agree
It is not clear what the second phase is. Backup plans only appear in BAL-005.
Disagree
This does conflict with the Functional Model. This may create a problem if and when an entity steps forward to register as the IA and perform the IA functions. We suggest the SDT consider reverting back to the existing applicability and assign this to the IA, but specify that given there are no entities registered as the IA and the default is the sink BA, all BAs are required to perform the IA function and hence need to register as one.
Disagree
We do not agree that this defined term is necessary; the concept can be described in the purpose without creating a new definition. Suggest the SDT coordinate the development of the Interchange Coordination definition with the Functional Model Working Group, which in its FM Version 5 has developed a definition for Interchange and Interchange Coordinator. Having different definitions for similar terms within the NERC documents tends to create confusion.
Disagree
Please see the comments to Question 2 above. Standards should be written to drive proper behaviors, not to specify the equipment and staff capabilities. The latter requirements belong to Organization Certification Requirements. (1) The term “desire to” is not needed as it makes the standard not measurable. Suggest to remove it from R1 and R3. (2) The majority of this standard deals with capability, not behavior. Suggest moving the requirements of this standard to Organization Certification Requirements.
Disagree
All transactions must be agreed to under any situations to ensure reliability. The proposed footnote and the added phrase appear to be adequate. No one should be found non-compliant if the hardware/software is not available to support these tasks, but we are not sure that these footnotes are the best way to achieve that goal. Can statements be made in the Measures and Compliance to address this?
Disagree
The mandate in the original set of standards has been missed. INT-001 establishes the mandate that special case interchange be explicitly assigned to some entity. In the case of Inadvertent Interchange payback, such payback can be initiated by either BA that has an accumulation, but R2.2 clearly mandates that the responsibility falls on the sink BA. The SDT should raise the issue of whether or not Inadvertent Interchange is a reliability issue or a business issue. Where INT-001 relates to a single Interchange, INT-009 relates the sum of all Confirmed Interchange and to the fact that the net of Confirmed Interchange only goes into the ACE equation. These are two distinct functions. INT-009 recognizes that NET Interchange is done among adjacent BAs. INT-001 assigns responsibility to BAs that may or may not be adjacent.
Agree
 
Disagree
INT-006 was designed to mandate the distribution of information. There is a possibility that an IA could collect approvals/denials and not inform anyone of the results. Hence there is a need to mandate that the data be distributed. If one agrees that the data be distributed, one could argue that there is a need to define the time-frame. The NAESB Tables bind the analysis and response times. The Timing Tables in INT-006-3 create a window of 1 minute between when confirmations are mandated and when they are implemented. Given the fact that it takes some time to change the values going into a BA's ACE equation there is not a lot of time to allocate. The one-minute period is consistent with the Tables. With respect to the specific requirements of R1, we agree with R1.1, but do not understand how R1.2, R1.3 and R1.4 apply to the general statement in R1 that addresses distributing ‘a request’ within a minute of its receipt. For example, if the request has not yet been distributed – how can it have been denied (R1.4)? We do not agree with R7.2, 7.3, 7.4. The general text of R7 is to requiring notification of whether or not AI was transitioned to Confirmed. The language of R7.2 implies something has already been distributed, yet the purpose of R7 is the actual distribution. If 7.3 or 7.4 are true the notification should be that is WAS NOT transitioned to Confirmed. If the intent is to only require notification of AI that was Confirmed, then the language of R7 needs to be modified to reflect that intent.
Disagree
The reliability reasons for denying an interchange request should be provided. With respect to economic markets, the reasons listed are appropriate, but the timing of their applicability should be reconsidered. For example, each market has submittal deadlines. Until those submittal deadlines have been reached, the system conditions are not fully understood and no action can be taken to ‘deny’ a request. For example, if a new interchange request, Request A, would result in the flow on an interface to exceed the transfer capability – another interchange request, Request B, may be submitted that would net against Request A. There is no reliability issue that needs to be addressed until the market deadline has passed.
Agree
 
Disagree
The phrase ‘shall not transition an Arranged Interchange to Confirmed Interchange’ appropriately utilizes the currently defined terms, but it is not clear what action should be taken – should there be a transition to a state of denied?
Disagree
(1) Potentially required is not measurable. (2) There is redundancy in R8 with TOP-005-2 R2. Also, R8 should be reworded for clarity. Suggest “Each Transmission Operator shall notify the Sink Balancing Authority(ies) when interchange schedules need to be modified to prevent a violation of a SOL or IROL.” (3) There is redundancy in R9 with IRO-001-1.1 R9 (all issues), IRO-009-1 R3 (Day Ahead IROLs), and IRO-004-2 R1 (the BA must follow directives). Also, R9 should be reworded for clarity. Suggest “Each Reliability Coordinator shall notify the Sink Balancing Authority(ies) when interchange schedules need to be modified to prevent a violation of an IROL.” Additional concerns are with respect to existing markets where submittal deadlines allow new interchange requests to occur up to ‘near real-time’. In that type of market environment an estimate of the net interchange would be available on a day-ahead basis but there is no expectation of taking action to modify specific interchange requests on a day-ahead basis.
Disagree
(1) The requirement assumes that it defines the complete set of exemptions. However, the IRO and TOP standards do a better job by mandating that the RC and TOP take actions for IROLs not just during an event but also if an event is anticipated. (2) This requirement is redundant with IRO-009-1 R4. What about when an adjustment is made because of failed checkout, or the economics of a transaction in a market?
Disagree
The word "composite" is confusing. Does it mean the net BA to BA interchange, or individual BA to BA interchange? The default when there is a disagreement is that the BAs must check each Interchange Schedule and not just Net Interchange. Does special consideration need to be given in the requirements (or only the Measures and Compliance) for known and planned hardware/software outages that could impact this process for more than one hour?
Disagree
No comments.
Disagree
As provided in Q9, Q12 and Q13 above, there may be special ‘interpretation’ required to ensure these requirements, as written, do not conflict with some FERC approved markets.
In INT-004-3 R1, the term “Load-serving, Purchasing-Selling Entity” is used and can cause confusion by making this standard appear to apply to Load-serving Entities as well as Purchasing-Selling Entities. A Purchasing-Selling Entity should have to adhere to these requirements whether or not it is serving retail load. “Load-serving” should be stricken from this requirement. There are several places where the Load Balancing Authority is used. Why is this term used instead of Sink Balancing Authority? INT-004: Why does an AI created based on the maximum MW value of a Dynamic Schedule never need to be modified? This seems to allow everyone to put in a maximum value and leave it unchanged for the duration of the interchange. INT-006: The term IA still exists in the timing tables. Also, the table requires distribution of Late and ATF AIs when the language in the requirements is only applicable to on-time AI. INT-009: The addition of the phrase ‘and maintain the generation-to-load balance’ in the Purpose does not seem to be consistent with the requirements of the standard; there are no requirements related to this action. Suggest removing. INT-010: The purpose of INT-010 indications that some Interchange Schedules should be exempt from compliance with ‘other Interchange Standards’. The requirements within INT-010 do not seem to be consistent with this purpose. INT-011: The Reliability Coordinator is in the Applicability section but is not mentioned in the requirements.
Individual
Angela P. Gaines
San Diego Gas & Electric
Agree
 
Agree
At present, there appears to be no issues with removing IA from these standards. However, in doing so, an expanded or new definition of BA should be developed that incorporates the functions originally assigned to the IA to insure clarity within the INT standards themselves, as well as any other standard where the BA adopts the IA functionality.
Agree
 
Agree
 
Disagree
There appears to be no clear reason as to why the footnoted phrase applies to similar requirements in one standard and not another. Therefore, the phrase should apply to similar requirements in all of the INT standards.
 
 
 
 
 
 
 
 
 
 
 
Although the term, "Load Balancing Authority" appears in the proposed new standard INT-011-1, and is also used in the approved Reliability Standard IRO-006-3, there is no definition of this term in the Glossary of Terms Used in Reliaibility Standards. A definition should be created. The use of the term, "Confirmed Interchange" seems to be different than the definition currently listed in the Glossary of Terms Used in the Reliability Standards. In addition, the present term still refers to the IA. A new or revised definition of Confirmed Interchange is necessary.
Group
SERC OC Standards Review Group
Jim Case
Agree
 
Agree
We completely agree: The IA should never have been coined as a term of art in NERC discussions.
Agree
 
Disagree
While the SERC OC Standards Review Group agrees that this list of tasks is appropriate and sufficient to arrange interchange, we believe requirements to have “capabilities” more properly belong in certification and this standard should be eliminated. Currently, only Reliability Coordinators (RCs), Balancing Authorities (BAs) and Transmission Operators (TOPs) must be certified. We recognize that eliminating this standard may require additional entities to be certified
Disagree
We agree with the intent of the language and the standards to which it is applied, but it needs to be explicitly in the requirements. Footnotes are not requirements.
Agree
 
Agree
 
Disagree
The SERC OC Standards Review Group cannot determine a reliability reason to have either R1 or R7. Further, we believe Requirements R1 and R7 as written are unclear, unmeasureable, and unenforceable.
Disagree
While we agree with R2.1 and reasons 1 and 3 of R3.1, the TSP cannot know projected system conditions as suggested in reason 2 of R3.1. This amounts to a preemptive TLR before the real time flows materialize.
Disagree
We generally agree with the intent of this new requirement. However, in the case of a co-owned unit serving load in two BAs via Confirmed Interchange, if that unit tripped, this requirement appears to saddle the Source BA with deleterious CPS and DCS results. It would seem that the Sink BA would be required to approve a curtailment, regardless of ramp, in this case. This situation appears to be more complicated than could be resolved with this requirement.
Agree
 
Disagree
How are the RCs and TOPs supposed to be able to know in advance of the real time flows exactly how many MWs of curtailment would be required in the case of a projected SOL or IROL exceedance? To what level of accuracy must these projections be made? What happens if the RC or TOP projects the wrong level of curtailment? Basically we don’t feel that FERC’s directive can be addressed without seriously damaging the energy market as we know it today.
Agree
 
Disagree
We agree with the SDT’s position. However, we assert that ramps should be verified to be identical as well.
Disagree
 
Agree
In questions 9 and 12, the SDT appears to essentially require a preemptive TLR anywhere from hours to a day in advance of the materialization of real time flows in excess of the real time capability of the transmission grid. This would inappropriately reduce the liquidity and optionality afforded by the current physical rights of tariffs for transmission service.
The SDT needs to review all INT standards, particularly INT-004-3, in regards to the applicability of the entities for those requirements. “The comments expressed herein represent a consensus of the views of the above named members of the SERC OC Standards Review group only and should not be construed as the position of SERC Reliability Corporation, its board or its officers.”
Individual
Steve Alexanderson
Central Lincoln
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
INT-004-3 R1 introduces a new entity type called the "Load serving, Purchasing-Selling Entity." This entity was left off the applicability list for the standard, and does not yet exist in the functional model or the registry criteria. Who exactly does R1 apply to?
Group
Midwest ISO
Nicholas Browning
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
Language should be added to define that the only responsibility to validate adjacency of a scheduling path (in 2.1) to a BAs own interconnection. Similarly, each TSP (in 3.1) will only be responsible to validate adjacency of a transmission path only to the extent of its interconnecting TSPs.
Disagree
Language should be changed to On-Time Reliability Adjustment Requests. "Late" (and even past-) requests MAY still be approved, but should not be a NERC defined "Must". E-Tag specifications may be changed to passively-APPROVE reliability adjustment requests to accommodate this standard, but that should only be automatic if the request is On-Time.
Disagree
Language is needed to more accurately define direct-current tie Operating Balancing Authority, and its communication role, as that role may not be otherwise designated in the e-Tag's approval path. As well, a DC portion of the transmission path may not be designated on an e-Tag, and may be completely unknown to the Sink Balancing Authority.
Agree
 
Agree
 
Disagree
Midwest ISO "agrees" to the intent of the requirement and that no default procedure is necessary. The requirement language should remove the words "No more than one hour". Scheduled interchange may be agreed to prior to that OH-1 along with other hours of static MW flow, for example. If this previously agreed-upon interchange schedule has not changed, no further communication should be needed.
Disagree
 
Disagree
 
 
Individual
Kasia Mihalchuk
Manitoba Hydro
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Disagree
 
Disagree
 
Disagree
 
 
Individual
Darcy O'Connell
California ISO
Disagree
The present INT Reliability Standards could use some “polishing” to eliminate redundancy and consolidate some Requirements, however, this SDT initiative seems to be primarily/solely(?) focused upon eliminating the IA function and responsibility, which is not appropriate, and which the CISO does NOT support.
Disagree
The IA IS an actual entity and must be, as Interchange management tracking tools (like the Western Interchange Tool or WIT for the WECC) are inanimate objects, and not capable of cognitive thought. The responsible party (IA) is the owner or operator of the tool, not the tool itself. The IA uses ITS tools to accomplish and fulfill its IA functional model role. In the West, the IA is the RRO, WECC, by way of 36 bilateral contracts. The California ISO believes the proposed NERC INT Standard changes advance substantial changes to the present Interchange Schedule standards and move away from the central coordinating responsibility of the Interchange Authority (IA), in our case WECC, which uses the WIT as the IA monitoring tool. Each of the BAs within the WECC helped develop and pay for development of the WIT. This IA function has worked well over the past two years, with clear lines of authority and responsibility, as documented in the IA contract with the RRO. When asked “what changes” with the SDT draft revisions, the answers to hardware? Software? Liability? Were all 3 nothing” responses. As such, we would oppose any movement away from the defined IA role, absent some substantive justification. WECC (as our IA in the West) and the WIT are the Interchange Authority and definitive keeper of all Implemented Interchange documentation, respectively. The Interchange Authority is an entity, and cannot be software. WECC was selected as the IA for the West and uses WIT as its IA tool. The CISO would not support movement away from IA authority towards dispersed Sink BA authority. You cannot have 37 BAs all responsible in the role of an IA to tell the other 36 what to do. Arranged Interchange must be mutually agreed upon and checked out, with oversight by the RRO as the IA. At present, the CISO has an IA services contract in place with WECC for this purpose. We strongly support use of the WECC WIT by all WECC entities. These proposed significant NERC Standard changes are contrary to the concept of the IA, and thus to the WIT as the definitive repository for arranged interchange. Further, it seems like an inefficient use of time to revisit the issue of the IA definition and role, especially so given the fact that this issue was previously resolved within the West by the WECC Interchange Scheduling Committee and the WECC Board, establishing the WECC, our RRO as our IA for the West. All 37 BAs negotiated and entered into IA contracts with WECC in this IA capacity accordingly in December 2008. The CISO supported and continues to support this convention, the present NERC IA definition and has been very pleased with the WIT as the WECC IA Tool as the definitive source of documentation for checked out NSI and NAI. With so many other critical matters before us, it seems an inefficient use of time to reopen a construct that is serving us well.
Disagree
Interchange coordination is inherent in the pre, RT and ATF checkout processes facilitated by the IA and the WIT tool in the West. Please see comment for Question #2.
Disagree
There are problems in this standard: R1.1 - “Load Balancing Authority” should be replaced with the defined term “Sink Balancing Authority” as defined in the NERC Glossary. R2.3 – Validate Requests for Interchange (RFI) section is missing the Energy Product validation used to determine if additional reserves are needed and is a valid reason to deny a tag. R2.4 – “Validate request to modify Interchange” is silent on the entities that have the rights/requirements for approval or denial. Curtailments should only require Source and Sink to approve that type of modification. Does “modify” really mean a market and/or reliability adjust? If so there needs to be a change to the terminology. R2.5 – Should indicate which entities are distributed the RFI. R2.6 – Should indicate which entities are distributed the RFI.
Disagree
 
Agree
 
Agree
 
Agree
 
Agree
An RFI missing the valid product Energy Code is also a reason for denial.
Agree
 
Agree
 
Disagree
R8 – the Requirement to have a TO notify a Sink BA of potential problems with modifications should be covered in the IRO Standards and not the Arranged Interchange Standards. R9 – The Requirement to have an RC notify a Sink BA of potential problems with modifications should be covered in the IRO Standards and not in the Arranged Interchange Standards.
No comment
No comment
Agree
Retain IA role and function. Retain Arranged and Implemented Interchange.
Agree
SDT draft change run counter to present IA contracts in the West, negotiated and entered into in good faith.
INT-004-3 Comments: In the WECC, the effective date is based on the “First day of the first calendar quarter following the date this standard is approved by applicable authorities.” R1.1 – The term “Load Serving, Purchasing-Selling Authority” should be changed to “Load-Serving Entity” as defined in the NERC Glossary. There is a question pertaining to “Reloading Transactions” in Question #7 of the accompanying questionnaire. INT-006-4 Comments: R1 – Appears to be missing the RFI distribution to the PSE. R2.1 – Missing valid energy product code is a valid reason for denial. R4 – Direct-current Tie Operator or Direct-Current Tie Operating Balancing Authority should be defined and added to the NERC Glossary. R8 – The requirement to have a TO notify a Sink BA of potential problems with modifications should be covered in the IRO Standards and not the Coordinate Interchange Standards. INT-009-2 Comments: Requirement numbering (R numbering and R sub-numbering) needs to be consistent between this and other INT Standards. R2 – The NERC definition defines the Net Interchange Schedule, it does not define Net Scheduled Interchange, although many use the terms interchangeably. What is meant by the use of the word “term”? INT-010-2 Comments: There is a need to identify the default entity that creates the tag in requirements R1-R3 as the Load Serving Entity. INT-011 Comments: R1.1 – “Load Balancing Authority” should be replaced with the defined term “Sink Balancing Authority” as defined in the NERC Glossary. R2.3 – Validate Requests for Interchange (RFI) section is missing the Energy Product validation used to determine if additional reserves are needed and is a valid reason to deny a tag. R2.4 – “Validate request to modify Interchange” is silent on the entities that have the rights/requirements for approval or denial. Curtailments should only require Source and Sink to approve that type of modification. Does “modify” really mean a market and/or reliability adjust? If so, there needs to be a change to the terminology. R2.5 – Should indicate which entities are distributed the RFI. R2.6 - Should indicate which entities are distributed the RFI.
Group
PPL Energy Plus
John Cummings
 
Agree
 
Disagree
The definition of “Interchange Coordination” appears only in INT-011 and it needs to be in all INT standards. Further, the definition should specify that a tool cannot be responsible for performance: registered entities are responsible for performance and the responsible entity required to carry-out such performance should be stated clearly in each standard.
Agree
 
Disagree
Footnotes 1&2 in INT-004-3 relieve all parties from the responsibility of assuring interchange takes place on the electric grid under poorly-defined circumstances. PPL believes removing responsibility for interchange under any circumstances places the reliability of the grid at great risk should critical software or hardware fail . A FAX, phone or other backup should be required to effect performance and this footnote should be deleted. This same footnote appears in the following standards and should be removed from all:  INT-006-4 Footnotes 2, 3, 5, 7, 8, 9, &10  INT-010-2 Footnotes 1, 2 & 3  INT-011-1 Footnotes 1, 2 & 3
Disagree
Unless dynamic schedules are tagged and identified in the Coordinated Interchange software that is used to develop the net schedule, they will never be curtailed using same software. This means all other schedules have a lower priority than Dynamic schedules and this should not be the case. We are not convinced that INT-009-2 R2 adequately conveys the requirement that dynamic schedules be tagged and tracked in curtailment software. Further, under R2.2: the word “Plus” is used to describe inclusion of a number (the Dynamic schedule) which may or may not be POSITIVE. It may be best to use a word other than “Plus” such as “including” or “summation” in order to provide clarification and accuracy.
Disagree
**Please re-insert R2 from INT-004-2 that requires a release and reload of interchange that has been curtailed. Please assure that in all cases, the PSE’s are kept informed of all curtailments and reloads. **R1: Loads with dynamic schedules are still the responsibility of the Sink BA who should be included as a responsible party. The old requirement that Sink BA’s arrange for dynamic schedules for Joint Owned Units (JOUs) and inadvertent payback is implied, but not stated. Please clearly state that the entity responsible for Arranging Dynamic Interchange for JOUs and inadvertent payback is the Sink BA in the new standards. **R2.3 requires the PSE to modify the dynamic schedule for reliability concerns communicated by the RC/TOP to the PSE’s. However, it does not appear that these INT standards require the RC/TOP to notify the PSE that a reliability concern exists and that the associated modification(s) or reload(s) must take place. Please insert such notification to the affected PSE(s) into the requirement.
Disagree
**R1: The reasoning behind R1.3 (less than the three-minute time) is not clear. In fact, R1.2 and R1.3 seem to be at odds with one another. Would the CI SDT please review the concepts under R1 and clarify the wording of sub-requirements 1.2 and 1.3? **R3.1 Item 1): Should “remaining for the TSR” be “remaining on the TSR”? **R3.1 Item 3): This requirement needs to allow for situations where the physical transmission path is intact, but a software tool does not have the right database model. In this case, a responsible entity should be allowed the discretion to allow the Interchange to flow regardless of the underlying software model. **R6: Sub-requirements 6.1 through 6.3 include a logical “and”. Should this be a logical “or”? **R7: The PSE (or other party originating Arranged Interchange) should be included in the list of parties notified of transition from Arranged to Confirmed. Please correct this omission.
Disagree
**R3.1 Item 1): Should “remaining for the TSR” be “remaining on the TSR”? **R3.1 Item 3): This requirement needs to allow for situations where the physical transmission path is intact, but a software tool does not have the right database model. In this case, a responsible entity should be allowed the discretion to allow the Interchange to flow regardless of the underlying software model.
 
Disagree
**R6: Sub-requirements 6.1 through 6.3 include a logical “and”. Should this be a logical “or”? **R7: The PSE (or other party originating Arranged Interchange) should be included in the list of parties notified of transition from Arranged to Confirmed. Please correct this omission.
 
Disagree
**This standard needs to apply to Reliability Coordinators if the PPL-proposed R5 (below) is included. **There may be occasions when a BA or TSP will not respond to a PSE request under R4. Because of possible non-response by the BA and/or TSP, R5 should be added to require RC’s to respond to a RFI from PSE’s (or possibly requests from all non-BA’s or non-TSP’s).
 
The CI SDT should be commended for their tremendous efforts to correctly assign responsibilities to the entities involved in Coordinated Interchange. PPL offers the following comments to support the CI SDT in their endeavors. 1)Since INT-011 describes what might be the first step in the sequence of events to establish Interchange, the rest of the standards should be numbered sequentially (i.e. INT-012, etc.). 2)The CI SDT needs to be prepared for the situation where all new standards are not approved by the FERC or all old standards are not approved for retirement by the FERC. We recognize that this is not the intent, but it remains a possibility. A solution may be to link the retirements to the approvals or combine the retirement into the new approved standard etc. INT-004-3 Dynamic Schedules Please re-insert R2 from INT-004-2 that requires a release and reload of interchange that has been curtailed. Please assure that in all cases, the PSE’s are kept informed of all curtailments and reloads. R1: Loads with dynamic schedules are still the responsibility of the Sink BA who should be included as a responsible party. The old requirement that Sink BA’s arrange for dynamic schedules for Joint Owned Units (JOUs) and inadvertent payback is implied, but not stated. Please clearly state that the entity responsible for Arranging Dynamic Interchange for JOUs and inadvertent payback is the Sink BA in the new standards. R2.3 requires the PSE to modify the dynamic schedule for reliability concerns communicated by the RC/TOP to the PSE’s. However, it does not appear that these INT standards require the RC/TOP to notify the PSE that a reliability concern exists and that the associated modification(s) or reload(s) must take place. Please insert such notification to the affected PSE(s) into the requirement. INT-006-4 Evaluation of Interchange R1: The reasoning behind R1.3 (less than the three-minute time) is not clear. In fact, R1.2 and R1.3 seem to be at odds with one another. Would the CI SDT please review the concepts under R1 and clarify the wording of sub-requirements 1.2 and 1.3? R3.1 Item 1): Should “remaining for the TSR” be “remaining on the TSR”? R3.1 Item 3): This requirement needs to allow for situations where the physical transmission path is intact, but a software tool does not have the right database model. In this case, a responsible entity should be allowed the discretion to allow the Interchange to flow regardless of the underlying software model. R6: Sub-requirements 6.1 through 6.3 include a logical “and”. Should this be a logical “or”? R7: The PSE (or other party originating Arranged Interchange) should be included in the list of parties notified of transition from Arranged to Confirmed. Please correct this omission. INT-009-2 Implementation of Interchange R2.2: the word “Plus” is used to describe inclusion of a number (the Dynamic schedule) which may or may not be POSITIVE. It may be best to use a word other than “Plus” such as “including” or “summation” in order to provide clarification and accuracy. INT-010-2 Initiating and modifying Interchange for Reliability This standard needs to apply to Reliability Coordinators if the PPL-proposed R5 (below) is included. There may be occasions when a BA or TSP will not respond to a PSE request under R4. Because of possible non-response by the BA and/or TSP, R5 should be added to require RC’s to respond to a RFI from PSE’s (or possibly requests from all non-BA’s or non-TSP’s). INT-011-1 Interchange Coordination Support (i.e. electronic tools to support interchange). R1: Please add wording to indicate that the Sink BA’s must be responsible for providing Arranged Interchange if a PSE cannot author an etag.
 
 
Individual
Louise McCarren
WECC
Agree
 
Agree
WECC supports the removal of the IA from the INT standards. WECC agrees that in the currently effective Functional Model and INT standards, the IA is not an actual entity (user, owner or operator of the bulk electric system) and strongly supports the direction of the CISDT. Corresponding edits to other standards, such as CIP-002 through CIP-009 and IRO-010, should also be made to reflect the removal of the IA.
Agree
 
Disagree
WECC does not have a comment on the tasks performed by the BAs, PSEs and TSPs. However, this standard lists the Reliability Coordinator in the Applicability section but there are no tasks, requirements or measures in the standard applicable to the RC. The RC should be removed from the applicable entity list. Furthermore, compliance measures and compliance monitoring information need to be identified in order for functional entities to fully understand what they will be responsible for and comment accordingly.
Disagree
WECC agrees with the general concept that such events should be considered as special cases in the INT standards. However, performance metrics should be associated with all of the requirements in the INT standards so compliance and the functional entity clearly understand their obligations. Specifically, with respect to degradation due to coincidental, accidental or malicious causes, a specific measure, such as a system availability threshold, should be identified.
Agree
 
Agree
 
Disagree
WECC agrees with the concept but the language is wordy and difficult to follow. Specifically, the CI SDT should consider whether the “and” is appropriate in this context. For example, 1.2 and 1.3 appear contradictory – how can an Arranged Interchange not transition to Confirmed Interchange and still have notice of the Arranged Interchange being transitioned to Confirmed Interchange. Perhaps a flow chart would be easier to understand. Also, emergency transactions can be entered in real-time or after the fact and may need to be specifically addressed. This also needs to be clarified. In general, however, WECC agrees that as long as the transaction is delivered when it was scheduled there is not a reliability issue.
Disagree
WECC does not have a comment on INT-006 base requirement R2. However, sub-requirement R2.1 is difficult to monitor for compliance. There is no way to measure or document whether a BA “expects” or “does not expect” to be capable of supporting the Interchange. Furthermore, R2.1 does not appear to enhance reliability. BAs have adequate authority to deny a tag for reliability and validity reasons without inclusion of this sub-requirement.
Agree
 
Agree
 
Disagree
Requirement R9 is not necessary, as the RCs have enough latitude in the existing IRO-004 to mitigate problems identified in the next day studies results. This requirement should not create redundancy or confusion with IRO-004.
Disagree
The RC needs to have the ability to use all its available tools to determine how to mitigate any potential issues on the BES. This requirement appears to unnecessarily limit the use of a Reliability Adjustment Request, and thus restrict the RCs use of this tool.
Disagree
this requirement should NOT be modified. It is appropriate as is.
Disagree
No requirements are missing.
Disagree
Not aware of any conflicts.
WECC is generally in favor of the revised INT Standards that are currently posted on the NERC Web site for a 45-day comment period, especially the removal of the IA from the INT standards. WECC recognizes that individual members within WECC may submit comments in opposition of this, and respects the rights of those members to differ with WECC’s opinion Another general comment is that the compliance measures and data requirements need to be clearly defined in order for entities to fully understand their responsibilities, and for Regional Entities to understand and develop a reasonable audit approach for the standards. WECC thanks the CISDT for the opportunity to provide comments.
Individual
Kirit Shah
Ameren
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1. The SDT should address if pseudo-ties should be shown so that they can be included in reliability tool (IDC) analysis. If they are to be excluded, please add a footnote stating it. 2. In INT-10, R4, an RFI acronym is used that is not defined either explicitly or parenthetically. Please include a definition. 3. In INT-11, be able to transmit "electronically" is unacceptable. Does this mean by email? This is electronic. If it means to use e-tag, please clearly state it as electronically is not good enough.
Individual
Leland McMillan
NorthWestern Energy
Agree
 
Agree
NorthWestern is concerned that BAs would have to accept the role of the IA. A Balancing Authority should not be held responsible for timing that is at the mercy of the software provider, Internet traffic, etc.
Agree
 
Disagree
NorthWestern is concerned that entities would have to accept the role of the IA. These entities should not be held responsible for timing that is at the mercy of the software provider, Internet traffic, etc.
Disagree
No registered entity should be held responsible for any incident outside its control.
Agree
 
Agree
 
Disagree
R1. R1 requires that the Sink Balancing Authority distribute each Arranged Interchange to the various entities specified in the Requirement “less than one minute after receipt of any Request for Interchange…” NorthWestern is very concerned by this requirement and strongly believes that a Balancing Authority should not be held responsible for timing that is at the mercy of the software provider, Internet traffic, etc. The time to act on a Request for Interchange can and must be managed by the Balancing Authority personnel, but placing the distribution time requirement on the Balancing Authority is unfair and misdirected. R4. It is unclear what “associated with a direct-current tie operator” means in the context of the Requirement. Does this mean that a Balancing Authority that is a direct-current tie operator must follow the requirement, or any Balancing Authority that receives a Request for Interchange that includes a direct-current tie operator as a party to the Request for Interchange? R7. The concern described for R1 also applies to the one minute notification timing requirement included within R7.
Agree
 
Agree
NorthWestern agrees, but has a separate issue with R4. It is unclear what “associated with a direct-current tie operator” means in the context of the Requirement. Does this mean that a Balancing Authority that is a direct-current tie operator must follow the requirement, or any Balancing Authority that receives a Request for Interchange that includes a direct-current tie operator as a party to the Request for Interchange?
Agree
 
Agree
 
Agree
 
Agree
 
Disagree
NorthWestern is not aware of any further requirements necessary for reliability.
Disagree
NorthWestern is not aware of any such conflicts.
NorthWestern appreciates this opportunity participate in the commenting process.
Group
Platte River Power Authority
Deb Schaneman
Agree
 
Agree
 
Agree
 
Disagree
Key tasks for Interchange Coordination has a reliability function, however, without defined Measures (TBD) it is difficult to determine how a registered entity will prove compliance during an audit other than demonstrating the use of an electronic tagging system. It seems inherently impossible to meet other INT Standards without the capability to meet the key tasks for Interchange Coordination. Therefore, we don't feel that these tasks must be specified in a standard as a requirement.
Disagree
If tools are unavailable due to a cyber attack or other incident, an entity such as the Reliability Coordinator should declare an emergency and have the authority to suspend interchange coordination or implement a procedure for manual interchange coordination. It should not be left to the Compliance Monitor’s discretion on a case by case basis to determine whether or not a violation of this requirement occurred.
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Disagree
 
Disagree
 
Disagree
 
 
Group
Entergy
Melinda Montgomery
Agree
 
Agree
 
Agree
 
Disagree
Having the capability to coordinate interchange more properly belongs in certification, so this standard should be eliminated.
Disagree
Entergy believes that this type of language is necessary to ensure compliance is not strictly enforced in situations where non-compliance is unintentional. However, we do not think that NERC’s enforcement of these standards will be influenced by footnotes, so we would propose that this language is more directly incorporated into the INT standards where appropriate.
Agree
 
Agree
 
Disagree
Entergy believes Requirements R1 and R7 as written are overly complex. Also, this standard seems to complicate interchange coordination without improving reliability.
Disagree
Entergy agrees with the requirement tied to Balancing Authorities (R2.1). Entergy does not agree with the requirement for Transmission Service Providers (R3.1) to deny based on projected system conditions as TSPs. The role of the TSP is to model available transmission capability, while the role of the Transmission Operators is to perform security assessments of the operating timeframe. TOPs currently do not have a role in interchange assessment, so we believe that the requirement should be removed.
Disagree
Entergy believes that curtailments are real-time reliability actions, and denials impair the reliability of the BES. Therefore, the language “if (the BA) can support the magnitude of the Interchange” decreases the effectiveness of curtailments for resolving reliability problems. Instead of the Balancing Authority which requires relief receiving it, the other BA(s) associated with the curtailed transaction may deny based on the burden to their system(s). The requirement language also implies that the BA denying such a curtailment may be failing their reserve requirements since they are unable to allow the curtailment request.
Agree
These criteria are correct, but Entergy would recommend adding an “if applicable” statement to the two requirements that list “the direct-current tie Operating Balancing Authority” since not all Reliability Adjustments include a DC tie.
Disagree
How are the RCs and TOPs supposed to be able to know in advance of the real time flows exactly how many MWs of curtailment would be required in the case of a projected SOL or IROL exceedance? Since interchange schedules can be submitted until a few minutes before ramp start, then the day-ahead assessments have limited impact on maintaining real-time reliability conditions.
Agree
 
Disagree
The standards should not specify the “how” of interchange checkout between BAs. Forcing adjacent BAs to perform hourly checkouts seems burdensome if Confirmed Interchange Schedules do not change between hours. Entergy recommends changing this requirement to remove the “No more than one hour prior to each operating hour” language in order to allow flexibility in checkout practices.
Disagree
 
Agree
In questions 9 and 12, the SDT appears to essentially require a preemptive TLR anywhere from hours to a day in advance of the materialization of real time flows in excess of the real time capability of the transmission grid. The preemptive curtailments should occur more closely to real-time so that the assessment is more meaningful to real-time system conditions.
 
Individual
Marcus Lotto
Southern California Edison Co.
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Disagree
 
Disagree
 
Agree
 
 
Group
NERC Staff
Gerry Adamski
Agree
 
Agree
 
Agree
 
Disagree
INT-011 does not appear to serve any specific reliability purpose, and seems primarily to be focused on requiring the use of software tools and procedures. While we believe there is value in the industry agreeing on a common set of tools and practices related to Interchange coordination, we question if they should be required in a reliability standard and monitored for compliance.
Agree
 
Agree
 
Agree
 
Disagree
The level of detail in these requirements seems intended to codify the behavior of software tools currently in use. While we believe there is value in the industry agreeing on a common set of tools and practices related to Interchange coordination, we question if they should be required in a reliability standard and monitored for compliance.
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Disagree
 
Disagree
 
Disagree
 
NERC believes the draft requirements are very well written, and offers its compliments to the CISDT. There are several terms used in the standards that do not appear to be defined in the NERC Glossary: "On-time Arranged Interchange," "Reliability Adjustment," “SOL,” “Transmission Facilities,” “Entity Registry,” and “Load Balancing Authority.” NERC suggests the CISDT either define these terms or consider alternate wording in the standard. In general, NERC asks the members of the CISDT and the industry at large if there is truly a need to have the all the details specified in the draft standards as mandatory and enforceable requirements. While we believe there is value in the industry agreeing on a common set of tools and practices related to Interchange coordination, we question if those tools and practices should be required in a reliability standard and monitored for compliance.
Individual
Ron Gunderson
Nebraska Public Power District
 
Agree
 
Agree
 
Agree
 
Disagree
The standard should outline the funtional requirements (redudancy in communications, servers, etc.) for the design of the tool. If the tool is meets design requirements, there should not be a standard violation if there are elements outside of the entities control that hamper the ability to respond to respond in the event of failure of the internet. Leaving the decision to the discretion of the auditor is ambiguous and inconsistent and places all risk on the entity involved on issues beyond the entity's control. This is not acceptable.
Agree
Although I agree the requirement can be retired, there is some question about the statement metered values for Dynamic Schedules. Not all Dynamic Schedules are metered (with traditional metering equipment). There needs to be a mechanism to document the final hourly interchange, but it is not necessarily a meter for Dynamic Schedules
Agree
 
Agree
Although we agree with the philosophy of the SDT to limit the one minute requirement for distributing Interchange information to only those cases that impact reliability, the requirements are anything but straightforward. Without the explanation at the beginning of the question, it would be very difficult to determine the intent. There should be a simpler way to implement the intent of the SDT.
Disagree
Although the reasons should be specified, we do not agree that the Source and Sink Balancing Authority needs to know proper connectivity throughout the entire path. Intermediate Balancing Authorities should verify connectivity to adjacent Balancing Authorities. It is unrealistic for the Source or Sink Balancing Authority to know the connectivity of all the Balancing Authorities in North America.
Disagree
Reliability Adjustment Requests should be approved period. To deny for lack of ramp will degrade the reliabiltiy of the interconnected system. For example, if an IROL is violated due to a sudden change in flow due to a contingency and a BA can deny the curtailment because it can't ramp in the change quick enough means there will be no relief when in fact there could be some relief if the change was ramped in as quickly as it could be. Another example is a DC tie trip between interconnections. The BA on the inverter side will experience a sudden and immediate loss of injection that probably will not be to serve load on its system and be expected to make up that loss just because another entity doesn't have enough ramp to meet the curtailment. This proposal doesn't make any sense from a reliability perspective. Curtailments for reliability reasons MUST be approved.
Disagree
Requirements 5.2 and 5.1 must include the BA on both sides of a DC line that crosses between interconnections. For a DC tie that crosses an interconnection, the Balancing Authorities on both sides of the DC Tie are effectively source/sink for the transaction in that interconnection and for that reason alone need to approve or deny the transaction.
Disagree
The standard should apply to RC's since they have the wide area view. The transmission operator should not be responsible for montioring IROLs as the RC should have the big picture for them.
Agree
Agree assuming that a DC tie is considered a Transmission Facility.
Disagree
 
Disagree
As noted above there are areas that are not clear and consise and at times are confusing. Also the notes to allow exceptions to timing requirements based on auditors discretion will not result in even treatment at times when extreme circumstances exist.
Disagree
 
Measures are missing for most standards. They need to be developed or the requirements removed. There should not be a requirement that cannot be measured.
Group
PJM
Patrick Brown
Disagree
The phased in approach is neither good nor bad. PJM however would suggest a simplified approach: – Stick to the basics for writing reliability requirements related to coordinating Interchange – i.e. RFI approval is required before implementation (no approval, no implementation) – make a clear distinction between tools (e-Tag) and entities – treat all RFIs the same no matter HOW they get implemented (i.e. dynamic schedules should be treated in the same way as normal schedules with regards to confirmation – and leave the Business rules to NAESB and the Markets) Regarding Dynamic Transfers, NERC needs to make clear that Dynamic Transfers are simply a means of implementing a Confirmed Interchange. A pseudo-tie is identical to a dynamic schedule and is not a means to avoid reserving transmission for a given point-to-point transaction.
Disagree
PJM does not agree that the IA should be removed from the standards. It should be noted that none of the NERC and FERC approval functional entities are “actual entities” until a corporate entity registers (or is registered) by NERC to comply with the standards written to the respective functions. The FM and the FMWG has consistently stated that the default position is that if no entity registers as an IA, then the Regional Entity must register someone and it is reasonable that the sink BA will be held responsible for the IA requirements. The SDT must address the issue that a software checkout tool is a means of checkout and is not the functional entity itself. PJM does agree that the failure of an INTERCONNECTION-WIDE tool should not be considered as non-compliance for the respective sink BA. The SDT should continue to seek consensus on rewording the standard such that BA compliance is based on the information provided to it (i.e. if the tool incorrectly provides confirmation on an Arranged Interchange (AI), and the BA acts in good faith on that information, then the requirement should recognize that the BA is compliant when it Implements that AI.) That does not mean that no one is responsible for checkout. A BA should never be excused from only implementing AIs that it knows or is informed has been confirmed. If there is no such knowledge or third-party confirmation, then there can not be any implementation of such not confirmed schedules.
Disagree
There is no need for the proposed new term. The SDT introduces a new term (Interchange Coordination) and uses the term in the title but the term is not used anywhere in the requirements. What the term also does is to further confuse the concept of a Task for coordination with the Tool used for coordination.
Disagree
Here again, the SDT presumes the need to remove the IA. That question should be asked before proceeding with requirements to replace the task. The tasks listed in INT-011 are business practices not reliability issues. INT-011 is written as a certification requirement. R2 (the main requirement) states that the BA must have the “capability” to do the following. Thus the sub-requirements refer back to capability, they are themselves NOT requirements that must be complied to
Disagree
No, the phrase does not help. The phrase "where Interchange Coordination is non-functional" seems to really mean "when the Interconnection wide tool isn't operating". If the tool isn't working then the sink BAs must do that checkout without the tool. But the checkout must be done, otherwise all RFI will / must be rejected because there will be no validation that everyone has agree to the proposed RFIs. Compliance monitors are not reliability entities. They are more likely to get around to investigating an event at the end of a month then they are to helping a real time concern. The footnote does not add anything to the standard. Compliance Monitors have always had discretionary options. Transaction information must be agreed to "in all cases". Without agreement BAs will be at risk of raising generation while another BA is dropping load. The only reasonable alternative is only to make changes that have been confirmed (with or without OATI)
Agree
The currently approved INT-001, as written, establishes responsibilities. PJM agrees that the elimination of this standard will not cause a problem for the simple reason that every other requirement establishes a responsible entity for the given task defined in the respective requirement. If done correctly the SDT only needs a requirement that Confirmed Interchange be transitioned to Implemented Interchange. There is no need to carve a special condition for Dynamic Schedules. If the Dynamic Schedule represents a point-to-point transaction it still requires that all parties agree with the terms of the transaction.
Agree
 
Disagree
PJM is satisfied that the reliability conditions are established and ensured by INT-003-2. The current and the proposed INT-006 impose subjective, unmeasureable procedureal mandates (e.g. the BA shall evaluate a schedule with respect to….) There are no measures associated with the current standard. PJM could support deleteing INT-006. The proposed INT-006 does correct the subjectivity of the old INT-006, but does so at the expense of imposing administrative guidelines that could, under emergency conditions, divert a system operator attention to focusing on RFI at the expense of evaluating system conditions.
Disagree
The reliability issue is whether or not the Interchange is approved or denied. The reasoning for that decision is not a reliability issue as much as it is a business issue. The idea of listing the reasons for denial merely limits the BAs reliability options for denying a business request. Being too busy to evaluate a request is a legitmate reason for denying a request that may or may not be harmful to the system (i.e. the BA does not want to operate in an unexamined system state.)
Disagree
A NERC requirement should not impose an ad hoc approval or denial. Each request must be evaluated in the context of the system conditions at the time.
Disagree
As in the response to Question 8, the reliability issue is the approval/denial of the Interchange. The rationale for approval/denial is a business issue. There is no reliability reason for imposing "passive approval" of AIs. "Passive denials" would be more reliable because it only accepts actively approved AIs thereby avoiding operations in an unexamined system state.
Disagree
R8 is redundant with TOP-005-2 R2 R9 is redundant with IRO-001-1.1 R9 (all issues) & IRO-009-1 R3 (Day Ahead IROLs)& IRO-004-2 R1 (the BA must follow directives).
Disagree
This is a Business issue not a reliability issue.
Disagree
The proposed requirement does not meet the FERC directive for clarity. The requirement must be clear regarding who is responsible for compliance. As written it is not clear which BA would be held non-compliant for a disagreement. The proposed requirement requires the BAs to ensure the validity of the data. The BAs need only decide on whether or not they can implement the Arranged Interchange based on the data. If the data is invalid the BAs must reject the request. As noted in the response to Q1, a better approach is to maintain a single requirement that if there is no agreement then there is no implementation.
Disagree
See response to Question 17.
 
PJM would suggest the SDT directly address the issues that they the SDT propose to remedy: 1. Define the data that must be coordinated for reliability • Magnitude • Start and end times • Rate of change • Source/sink 2. Distinguish between coordination tools and reliability entities. For example: Require that BAs only implement CONFIRMED INTERCHANGE; then as sub-requirements list the acceptable means of doing that: • By using an Interconnection-wide tool that the BAs will use as the basis for demonstrating that they met the coordination requirement for each CI; or • By BA-to-adjacent BA checkout where using the same inter-area net values as confirmation that they met the coordination requirement 3. Seek NERC approval to make the data in the interconnection wide tool available to the RC for review. PJM does not agree that the RC should be included in the interchange coordination process because the TOP and RC currently (IRO-001-1 R3 to R9) has the authority to reject any schedule at any time that it deems the system is or will at risk (IRO-004-2 R1) Let NAESB define and maintain the timing requirements and the boundaries for what can and cannot be used for Dynamic Schedules. [As long as both BAs agree to the magnitude of a schedule, the system will be in balance.]
Group
Bonneville Power Administration
Denise Koehn
Disagree
Dynamic Transfers should be addressed in a single standard. All dynamic transfers have an impact on the grid and should be treated equally and simultaneously in standards development. Addressing dynamic schedules while leaving pseudo ties out of the requirements leaves a huge hole in the standard. Standards dynamic schedules and pseudo ties should be developed in a single phase. Please advise the CI SDT to be cognizant of the downstream effects that multiple Standard revisions create. Each time a new Standard version is issued, staff responsible for demonstrating compliance is required to provide documentation covering each period of time within the calendar year that each version is in effect. Multiple Standard versions within a calendar year create a lot of documentation efforts. Please limit versions to the minimum number possible.
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
We agree with the approach. However, how does the Sink Balancing Authority demonstrate compliance with the less than one minute distribution requirement? Will each tagging software vendor provide a check that records or logs the demonstration of each distribution’s meeting the 1-minute-or-less threshold? We believe the data is logged today. We’re not certain that a check is made to ensure distribution occurs within a minute or less timeframe as well as documented evidence of such.
Disagree
We are struggling with how a Transmission Service Provider proves that it denied Arranged Interchange whenever its transmission system did not have the capability to accommodate Arranged Interchange based on “projected system conditions”. The latter term is vague and seems difficult to validate that whenever such conditions occurred, the TSP responded with denial actions.
Agree
 
Agree
 
Agree
 
Agree
 
Disagree
 
Disagree
 
Disagree
 
Some of the revised Standards (e.g., INT-006-4) tend to have wordy requirements that make them not only difficult to interpret but also make demonstration of compliance more complex. Shorter, very specific language is preferred.
Group
FirstEnergy
Sam Ciccone
Agree
We agree with the two phase approach. However, we ask for clarification: Does this mean the SDT will ballot the first phase standards and obtain FERC approval while working on phase two?
Agree
 
Disagree
The definition of Interchange Coordination in the standards should be consistent with, build on, and support the definition of Interchange Coordinator in the Functional Model Version 5. Consequently, we suggest the following adjustment to the definition of Interchange Coordination – "The act of using commonly available tools to ensure the communication of Arranged Interchange for reliability evaluation purposes and coordination of implementation of valid and balanced Confirmed Interchange between Balancing Authority Areas including full disclosure to all the parties involved."
Disagree
Fundamentally, the approving and denying of Arranged Interchange is the reliability-related task that initiates a transaction’s implementation process. Consequently, that approval process and the implementation process are what need to be included in the standard. The rules concerning the submission of a request are business practices that should be determined by NAESB. The only requirement that a PSE should have a method for providing the Request for interchange electronically and that the information they provide related to that request is accurate and complete.
Disagree
It seems the drafting team's statement, "In cases where Interchange Coordination is non-functional or has been degraded due to coincidental, accidental, or malicious causes, the Compliance Monitor may exercise discretion in determining whether or not a violation of this requirement has occurred." assigns a compliance auditor an authority that they already have. This statement seems unnecessary. As an alternative the drafting team should require an entity to document and implement a manual process when the electronic capability (tool) is unavailable. Furthermore, in those extreme circumstances, the Standards of Conduct and Market Activity will be suspended and interchange activity will by necessity be managed by the BAs and TOPs.
Agree
 
Agree
 
Disagree
The one minute time limit appears to have sprung from the e-tag system specifications document and was related to ensuring market activity was unimpeded (i.e. first request through the door was the first request considered for implementation). The speed with which these transactions are managed is a market issue. The requirement should be to implement the schedule as approved. R1 and R7 may be difficult to measure and prove compliance during times of system failures. In R1.1 and R7.1 it is not clear what constitutes "on time."
Disagree
This requirement appears to limit the "reliability reasons" for denying a transaction to only those listed. We seem again to be mixing business practices with reliability-related issues. In R3.1, the transmission path is contractual and may not accurately represent the actual flow; therefore, this may be a market issue and may not directly be a reliability issue.
Disagree
Reliability Standards should not require the approval of market related transactions. The BA should only be required to deny a transaction if it cannot reliably implement the proposed transaction. The rules and requirements for approving transactions belong in the NAESB WEQ.
Disagree
Reliability Standards should not require the approval of market related transactions. The BA should only be required to deny a transaction if it cannot reliably implement the proposed transaction. The rules and requirements for approving transactions belong in the NAESB WEQ.
Agree
However, R9 is contained in R8. The "or IROL" should be deleted from R8 as it is covered by R9.
Disagree
4.1 and 4.2 are contractual arrangements that do not necessarily equate to a reliability issue. R4.3 may or may not represent a reliability concern. The statement "provided that concern is supported by evidence" in R4.5 is heavy handed. It implies that Mr. BA, TSP, or RC may cut the transaction, but you better make sure you have evidence to support that decision. By requiring these entities to adjust the transaction for "Any real-time reliability concern related to a specific Confirmed Transaction" you directly require evidence to prove compliance with the requirement. This makes the phrase "provided that concern is supported by evidence" in R4.5 redundant and unnecessary. It should be deleted.
Agree
NOTE: We clicked "Agree" in the on-line comment form to signify that we agree with the SDT's choice to not specify a method to reach agreement when conflicts arise. However, it is not unreasonable that a business rule be written that requires resolution of conflicts procedure. It is also reasonable to allow reliability entities to not implement a transaction that has not been agreed to by everyone prior to implementation.
Agree
NOTE: We clicked "Agree" in the on-line comment form to signify that we do not think there are any requirements missing. However, it appears throughout the standards development that the drafting team is mixing business practices with reliability-related issues. A review by the team of the proposed standards to ensure that business practices are managed by NAESB and reliability issues are housed in the NERC Standards is appropriate and necessary.
Agree
NOTE: We clicked "Agree" in the on-line comment form to signify that we are not aware of any conflicts between the proposed standards and any regulatory function, rule/order, tariff, rate schedule, legislative requirement or agreement.
FE has the following additional comments: 1. It seems the drafting team’s statement, "In cases where Interchange Coordination is non-functional or has been degraded due to coincidental, accidental, or malicious causes, the Compliance Monitor may exercise discretion in determining whether or not a violation of this requirement has occurred." assigns a compliance auditor an authority that they already have. This statement seems unnecessary. The requirement should allow the reliability entity to suspend market operations and Standards of Conduct when extreme situations such as where Interchange Coordination is non-functional or has been degraded due to coincidental, accidental, or malicious causes. The circumstances cited truly represent a threat to reliability on an emergency level that 888 and 889 envisioned with the inclusion of a provision to suspend market operations during an emergency. 2. INT-004-3 – (a) Applicability and Req. R2.3 – Although the standard applicability section and Req. R2.3 lists the Transmission Operator (TOP), the TOP does not appear to have any responsibilities. Main Req. R2 is only applicable to the Purchasing-selling Entity. We suggest that the SDT remove the TOP from the applicability section A.4. (b) In Req. R1, the phrase "Load-serving, Purchasing-Selling Entity...", we feel that the phrase is awkwardly written and may be misinterpreted to place responsibility on the functional entity "Load-Serving Entity". We suggest rewording R1 as follows: "The Purchasing-Selling Entity that provides Load associated with a Dynamic Schedule shall ensure...". 3. Effective Date – We feel that the proposed effective date of the "first day of the first calendar quarter following the date this standard is approved by regulatory authorities..." does not provide the entities appropriate time to implement these extensive changes. From a compliance evidence standpoint, the changes will create much additional work due to all the revised, transferred, and retired requirements. Also, INT-011-1 is a new standard and there may be responsible entities that will need adequate time to provide the required support for interchange coordination. We suggest the SDT consider increasing the implementation period by at least two calendar quarters. 4. We noticed that the VRF and Time Horizons are not shown in the draft requirements. Is the SDT planning to develop these in a later draft?
Group
GSOC & GTC Response
Guy Andrews
Agree
 
Agree
 
Agree
 
Disagree
The requirements as listed in the standard are not to perform the tasks, but to be capable of performing them. This standard reads more like a list of requirements for certification rather than a measure of compliance. It’s misplaced as a standard.
Disagree
We understand the intent here but believe that the footnote language should be moved into the requirements to make them part of the standard. Requirements and measurements should not be listed in footnotes.
Agree
 
Agree
 
Disagree
Remove these requirements completely.
Disagree
Postings and associated reservations made on OASIS are based on studies. The TLR process is defined for curtailments.
Agree
 
Agree
 
Disagree
It seems out of scope for a TOP to manage or predict next day real time flows in order to accurately curtail transactions.
Agree
 
Disagree
Requirements should specify what must be accomplished – not tell how an entity should accomplish it. Procedures should be left up to the entities.
Disagree
 
Disagree
 
 
Group
Midwest ISO Stakeholder Standards Collaborators
Jason L. Marshall
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
Reloading of transactions does not support reliability but rather supports continuance of commercial activity once the reliability event is over. Thus, reloading of transactions does not belong in reliability standards. It would be an issue better dealt with by NAESB.
Agree
 
Agree
Language should be added to define that the only responsibility to validate adjacency of a scheduling path (in 2.1) to a BAs own interconnection. Similarly, each TSP (in 3.1) will only be responsible to validate adjacency of a transmission path only to the extent of its interconnecting TSPs.
Disagree
Language should be changed to On-Time Reliability Adjustment Requests. "Late" (and even past-) requests MAY still be approved, but should not be a NERC defined "Must". E-Tag specifications may be changed to passively-APPROVE reliability adjustment requests to accommodate this standard, but that should only be automatic if the request is On-Time.
Disagree
Language is needed to more accurately define direct-current tie Operating Balancing Authority, and its communication role, as that role may not be otherwise designated in the e-Tag's approval path. As well, a DC portion of the transmission path may not be designated on an e-Tag, and may be completely unknown to the Sink Balancing Authority.
Disagree
These requirements are not needed and will only duplicate existing requirements that adequately address the need to assess interchange transactions on a day-ahead basis. IRO-004-1 R1 already requires Reliability Coordinators to perform next day studies for “anticipated” conditions “to identify potential interface and other SOL and IROL violations. Day ahead energy schedules would clearly fall into anticipated conditions. IRO-004-1 R2 requires each Reliability Coordinator to “pay particular attention to parallel flows”. Again day ahead energy schedules fall into this parallel flows. IRO-004-1 R3 requires each Reliability Coordinator to develop action plans that may be required to alleviate IROL and SOL violations. One option for the action plans explicitly states curtailment of Interchange Transactions as an option. IRO-004-1 R6 requires the Reliability Coordinator to direct action to alleviation these IROL and SOL violations identified in the next day studies and IRO-004-1 R7 requires the Transmission Operator, Balancing Authority and Transmission Service Provider to comply with the directives based on the results of these next day studies. TOP-002-2 R5 requires Transmission Operators to plan to meet “scheduled system configuration, generation dispatch, interchange scheduling and demand patterns”. TOP-002-2 R11 requires the Transmission Operator to perform a next day study. Thus, a Transmission Operator would have to include day-ahead interchange schedules in its next day study in order to plan to meet them. Then TOP-002-2 R10 requires the Transmission Operator to plan to operate within IROLs and SOLs.
Agree
 
Disagree
Midwest ISO "agrees" to the intent of the requirement and that no default procedure is necessary. The requirement language should remove the words "No more than one hour". Scheduled interchange may be agreed to prior to that OH-1 along with other hours of static MW flow, for example. If this previously agreed-upon interchange schedule has not changed, no further communication should be needed.
Disagree
 
Disagree
 
 
Individual
James H. Sorrels, Jr.
American Electric Power (AEP)
Disagree
 
Disagree
Currently, there are applicable entities in the NERC functional model which are registered as IAs. We believe that the current process is not broken and that the IA just needs to be better defined. Note: Please refer to question 17 for additional comments on the rewrite of the Standards.
Disagree
 
Disagree
The different RTO and Market models across the BES compromise the intent of the Standard and Requirements. As a result, they are not properly represented with what actually takes place in the Interchange Scheduling process. Also, they do not address the current involvement of PSE or CPSE relationship to the BAs. Note: Please refer to question 17 for additional comments on the rewrite of the Standards.
Agree
 
Agree
We agree that it is unimportant who creates the Arranged Interchange. Confirmation by all affected applicable and reliability entities are what are ultimately important.
Disagree
This should pertain to all impacted Interchange Schedules, where the releasing entity should electronically notify release of reliability profile curtailment. Verbally, as a backup, if the electronic process has failed to ensure Sink BA ultimately as needed.
Disagree
We do not agree that Sink BA should be responsible to distribute. This should be a function of IA or NERC.
Disagree
Different Market models and structure, such as SPP, do not line up with the intent of what this Standard is trying to accomplish. While we agree with intent, concept and approach, they are not reflective of the different Market models currently in operation today.
Agree
When it involves a reliability request, all applicable entities should try to accommodate to the best of their ability. Magnitude and ramp may actually be a less significant factor than unloading a transmission line or shedding load based on the situation.
Agree
Active approval and reliability assessment should always occur.
Agree
 
Agree
 
Agree
The present SPP structure and EIS Market needs to be addressed, while still having individual BAs needs addressed to meet the intent of this Standard.
Agree
Please refer to question 17 for additional comments on the rewrite of the Standards.
Agree
Yes, different Market models and structure, such as SPP.
INT-004-3 Rewrite Comments: The purpose statement should also include pseudo tie interchange besides the dynamic schedule reference. While BAL-005-0.1b deals the metering aspect, it does not address that in many cases the pseudo tie interchange is not being accounted for appropriately in the NERC IDC. This was a very apparent finding from the Northeast Blackout of 2003. The unscheduled flows and reliability impact of pseudo ties still remains a problem today. Regardless of where the BA has the pseudo tie is contractually modeled to, the affecting source or sink impact on reliability still comes from the response factor of actual physical location. R1: If the Load-serving PSE is only responsible for ensuring the RFI is submitted to the Sink BA, who is responsible for making sure the Source BA has the same confirmed schedule intent to ensure generator to load balance? This could imply the Source BA does not need to know, while it is presently a function of the Interchange Authority and its electronic process. R2 and its sub-requirements: The BES does not operate to average energy profile values. It operates to real-time values and changes. Average energy profile is a Market accounting and settlement term, which has no place in real-time operation or its tools/process, such as IDC or interchange scheduling, for managing congestion or reliability impact. R2.3: The average energy profile term is used in the preceding requirements, yet the hourly energy profile term is used in R2.3. All reliability impact is based on the actual operating value at a specific time, regardless of what is on the forecasted dynamic schedule value. These actual operating values are not continually identified in the IDC, which accounts for the unscheduled flow issue. This is why it is extremely important to continually have the forecast dynamic schedule match the impact of the actual operating value. Actual operating values can different greatly from forecasted dynamic average energy profile, enabling the root cause to not be identified in IDC and forcing other interchange to be curtailed instead. The intent of Standard INT-004-3 is to address a needed reliability process. However, it does not cover the impact of unscheduled flows caused by pseudo tie interchange. The requirement parameters for deviation are reactive in addressing the actual operating impact, just as the IDC curtailment process is sometimes reactive. Since the maximum actual energy cannot exceed the transmission reservation that has already been reliably assessed in the OASIS reservation/priority process, we recommend the PSE continually matching forecasted dynamic schedule to actual operating value and communicate to the IDC. It might be impossible to do this on forecasted dynamic schedule interchange that frequently changes with significant magnitude. The only way to realistically accomplish identification and communication of reliability impact to the IDC would be to somehow send these actual interchange values. INT-006-4 Rewrite Comments: R1 Proposing that the Sink Balancing Authority shall be exclusively responsible for distributing Arranged Interchange is totally contradictory to the Interchange Scheduling process and purpose of the Interchange Authority in the present NERC functional model. It appears to put all the burden of arranging and distributing AI to the Source BA. This concept appears to be going back to the days of and former model of Control Area and bundled utility, in which adjacent CA’s confirmed interchange schedules. In today’s model, open access Market and all of the granular applicable involved entities in the NERC functional model and process, it does not seem realistic for the Sink BA to be responsible for distribution in an electronic E-Tag process environment. Many NERC approved Regional Transmissions Organizations (RTOs) have different models and interchange scheduling tools, processes and congestion management mechanisms. They are also registered as the Interchange Authority in the NERC functional model. There is nothing wrong with the current electronic scheduling process (E-Tag and Vendor Tagging Authority). NERC and the Industry would be better served to clearly define what the applicable IA entity really is and means. Possibly, NERC should be the IA responsible for the electronic process and backup for distributing the necessary interchange scheduling and reliability information to the applicable entities defined in its functional. It makes sense for the current RTOs, such as PJM, SPP, etc., to be registered as the IA for their areas. It should be up to them how this interchange information is distributed within the intent of the NERC Reliability Standard through their choice of vendor, electronic tagging authority specifications and contract to meet the Requirements. The second option should be NERC itself. How can a Sink BA be responsible in an open access/Market environment with all of the multiple entities involved? The Sink BA does not actually make the Request for Interchange (RFI) or arrange the interchange. The affiliated PSE or designated CPSE does through its Tagging Authority service and the NERC Interchange Authority E-Tag process. R2.1: There are many aspects that can compromise a Source or Sink BA’s ability to determine the meeting of the magnitude of Interchange and ramp. With the different RTO and ISO models, especially with respect to Market protocols and impacting granular entities, such as Independent Generator Operators, how can a BA solely determine capability of supporting ramp? For example: In the Southwest Power Pool/RTO and Energy Imbalance Schedule Market model SPP is the tariff administrator, transmission service provider, scheduling control area (SCA - according to the OATI IA tool) and it deploys Market Participant GOPs. Yet it has individual membership BAs responsible for demonstrating the ability to meet ramp and magnitude of Interchange to meet performance standards involving generation to load balance, while the Market is deploying GOP resources that could contradict this effort. Applicability: Agree with adding the 4.3 Reliability Coordinator and 4.4 Transmission Operator entities. INT-009-2 Rewrite Comments: In the case of Markets, such as SPP, where there are continual market interval Interchange changes of significance impact on ACE and deployments to independent GOPs that do not follow the intent of meeting generation to load balnce, who is responsible for confirming before implementation into the member BAs’ ACE equations? Also, see comments above in R2.1. These types of Market models compromise the intent of meeting the generation to load concept meant to be addressed in the Balancing and Interchange Standards. Retirement of Standards Comments: The current IA process and concept should remain but needs to be better defined. If not, NERC should administer the IA process and electronic Interchange distribution of RFI and AI to the affected/applicable reliability entities for assessment and approval.
Individual
Greg Rowland
Duke Energy
Agree
 
Agree
We agree with removing the IA. However does elimination of the IA place more compliance responsibility on the Sinking BA? And is the Sinking BA the appropriate entity? As opposed to the Purchasing Selling Entity, for example?
Agree
 
Disagree
We agree that the lists of tasks are appropriate and sufficient to arrange interchange. However requirements to have “capabilities” should be certification requirements and do not belong in a Reliability Standard. This standard should be eliminated.
Agree
 
Agree
 
Agree
 
Agree
 
Agree
We agree, but believe that the language could be more clear that you are only responsible for validating paths relevant (i.e. adjacent) to your system.
Disagree
Language should be clarified such that only On-Time requests should be REQUIRED to be approved.
Agree
 
Disagree
We believe that these requirements are more appropriately addressed in the IRO standards, rather than in the INT standards.
Agree
 
Disagree
 
Disagree
 
Agree
In questions 9 and 12, the SDT appears to essentially require a preemptive TLR anywhere from hours to a day in advance of the materialization of real time flows in excess of the real time capability of the transmission grid. This would inappropriately reduce the liquidity and optionality afforded by the current physical rights of tariffs for transmission service.
• Given that the BA has been given additional responsibilities, where and how are the specifications for INT transactions defined? The drafting team needs to address this issue. • INT-009-2 Requirement R1 – for this requirement, you should not have to re-confirm schedules that have not changed from previous hours.
Group
PacifiCorp
Sandra Shaffer
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Disagree
In cases of reliability adjustments (curtailments), PacifiCorp does not believe that there are any valid reasons for denying a curtailment.
Agree
 
Disagree
 
Agree
 
Disagree
The words “no more than one hour prior to each operating hour” are ambiguous and could potentially be interpreted to preclude a preschedule check-out. To clarify, PacifiCorp suggests that the language read “at least one hour prior to each operating hour….” or, in the alternative, the words “no more than one hour prior to each operating hour” should be eliminated entirely.
None at this time
None at this time
None at this time
Individual
Kathleen Goodman
ISO New Enlgand Inc.
Agree
 
Agree
We agree that assigning the standard requirements, as suggested, to the Sink BA does not conflict with the functional model. Since there may be more than one Interchange Coordinator, the assignment of these requirements to the Sink BA provides clear guidance to the industry on the entities that are responsible for these functions and does not raise additional questions of interpretation that the assignment to the IC could create.
Disagree
We do not agree that this defined term is necessary; the desired concept can be described in the purpose without creating a new definition.
Disagree
We agree with the concept of including the required tasks in the standards; and with the current layout of the other standards putting them all within INT-011 is a reasonable approach. However, the phrase “that desires to” is not measureable and should be removed.
Disagree
We agree that no one should be found non-compliant if the hardware/software is not available to support these tasks, but we are not sure that these footnotes are the best way to achieve that goal. Can statements be made in the measures and compliance to address this rather than a footnote?
Disagree
The SDT seems to have missed the distinction made in the original set of standards. INT-001 establishes the mandate that special case interchange be explicitly assigned to some entity. In the case of Inadvertent Interchange payback, such payback can be initiated by either BA that has an accumulation, but R2.2 clearly mandates that the responsibility falls on the sink BA. The SDT would be better served to raise the issue of whether or not Inadvertent Interchange is a reliability issue or a business issue. Where INT-001 relates to a single Interchange, INT-009 relates the sum of all Confirmed Interchange and to the fact that the net of Conformed Interchange only goes into the ACE equation. These are two distinct functions. INT-009 recognizes that NET Interchange is done among adjacent BAs. INT-001 assigns responsibility to BAs that may or may not be adjacent.
Agree
 
Disagree
While we agree with the general approach of INT-006, we have the following comments/questions. With respect to the specific requirements of R1, we agree with R1.1, but we do not understand how R1.2, R1.3 and R1.4 apply to the general statement in R1 that is talking about distributing ‘a request’ within a minute of its receipt. For example, if the request has not yet been distributed – how can it have been denied (R1.4). We do not agree with R7.2, 7.3, 7.4. The general text of R7 is to requiring notification of ‘whether or not AI was transitioned to Confirmed. The language of R7.2 implies something has already been distributed, yet the purpose of R7 is the actual distribution. If 7.3 or 7.4 are true the notification should be that is WAS NOT transitioned to Confirmed. If the intent is to only require notification of AI that was Confirmed, then the language of R7 needs to be modified to reflect that intent.
Agree
We agree that the list of reasons for denial should be provided in the standard and are appropriate. However, with respect to economic markets, we believe the timing of the reviews should be reconsidered; or an exemption may be required for these timelines in areas with economic markets. For example, in economic markets with submittal deadlines, the system conditions for evaluation of the Arranged Interchange is not understood until those submittal deadlines have passed. Therefore, no action can be taken to ‘deny’ a request in the timeframes noted. For example, if a new interchange request, Request A, would result in the flow on an interface to exceed the transfer capability – another interchange request, Request B, may be submitted that would net against Request A. There is no reliability issue that needs to be addressed until the market deadline has passed.
Agree
 
Disagree
The phrase ‘shall not transition an Arranged Interchange to Confirmed Interchange’ appropriately utilizes the currently defined terms, but it is not clear what action should be taken. Should there be a transition to a state of denied?
Disagree
We do not believe these new requirements are appropriate for the following reasons: (1) “Potentially required” is not measurable (2) R8 is redundant with TOP-005-2 R2; and (3) R9 is redundant with IRO-001-1.1 R9 (all issues) & IRO-009-1 R3 (Day Ahead IROLs)& IRO-004-2 R1 (the BA must follow directives). (4) In existing economic markets, where submittal deadlines allow new interchange requests to occur up to ‘near realtime’, an estimate of the net interchange would be available for coordination on a day-ahead basis but there is no expectation of taking action to modify specific interchange requests on a day-ahead basis as the requirements indicate.
Disagree
(1) The requirement assumes that it defines the complete set of exemptions. However, the IRO and TOP standards do a better job by mandating that the RC and TOP take actions for IROLs not just during an event but also if an event is anticipated. (2) This requirement is redundant with IRO-009-1 R4 (3) These specific reasons do not allow the BA or TSP to make an adjustment is made because of failed checkout or the economics of a transaction in a market. Where are those adjustments allowed?
Disagree
The word "composite" is confusing. Does it mean the net BA to BA interchange or individual BA to BA interchange? The default when there is a disagreement is that the BAs must check each Interchange Schedule and not just Net Interchange. Should special consideration need to be given in the requirements (or only the measures and compliance) for known and planned hardware/software outages that could impact this process for more than one hour?
 
Disagree
As provided in Q9, Q12 and Q13 above, there may be special ‘interpretation’ required to ensure these requirements, as written, do not conflict with some FERC approved markets.
General: There are several places where the Load Balancing Authority is used. Why is this term used instead of Sink Balancing Authority? INT-004: Please describe why an AI created for the based on the maximum MW value of a Dynamic Schedule should never need to be modified. This seems to allow everyone to put in a maximum value and leave unchanged for the duration of the interchange. INT-006: The term IA still exists in the timing tables. The table requires distribution of Late and ATF AIs when the language in the requirements is only applicable to on-time AI. INT-009: The addition of the phrase ‘and maintain the generation-to-load balance’ does not seem to be consistent with the requirements of standards; there are no requirements related to this action. Suggest removing. INT-010: The purpose of INT-010 indications that some Interchange Schedules should be exempt from compliance with ‘other Interchange Standards’. The requirements within INT-010 do not seem to be consistent with this purpose. INT-011: The Reliability Coordinator is in the Applicability section but is not mentioned in the requirements
Group
NERC Standards Review Subcommittee
Carol Gerou
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Disagree
Language should be added to specify that the BA’s only responsibility is to validate connectivity of the adjacent scheduled path (in 2.1) to a BAs own interconnection. Similarly, each TSP (in 3.1) will only be responsible to validate connectivity of the adjacent transmission path only to the extent of its interconnecting TSPs.
Disagree
Language should be changed to On-Time Reliability Adjustment Requests. "Late" (and even past) requests MAY still be approved, but should not be a NERC defined "Must". E-Tag specifications may be changed to passively-APPROVE reliability adjustment requests to accommodate this standard, but that should only be automatic if the request is On-Time.
Disagree
Language is needed to more accurately define direct-current tie Operating Balancing Authority, and its communication role, as that role may not be otherwise designated in the e-Tag's approval path. As well, a DC portion of the transmission path may not be designated on an e-Tag, and may be completely unknown to the Sink Balancing Authority.
Disagree
A. These requirements are not needed and will only duplicate existing requirements that adequately address the need to assess interchange transactions on a day-ahead basis. IRO-004-1 R1 already requires Reliability Coordinators to perform next day studies for “anticipated” conditions “to identify potential interface and other SOL and IROL violations. Day ahead energy schedules would clearly fall into anticipated conditions. IRO-004-1 R2 requires each Reliability Coordinator to “pay particular attention to parallel flows”. Again day ahead energy schedules fall into this parallel flows. IRO-004-1 R3 requires each Reliability Coordinator to develop action plans that may be required to alleviate IROL and SOL violations. One option for the action plans explicitly states curtailment of Interchange Transactions as an option. IRO-004-1 R6 requires the Reliability Coordinator to direct action to alleviation these IROL and SOL violations identified in the next day studies and IRO-004-1 R7 requires the Transmission Operator, Balancing Authority and Transmission Service Provider to comply with the directives based on the results of these next day studies. B. TOP-002-2 R5 requires Transmission Operators to plan to meet “scheduled system configuration, generation dispatch, interchange scheduling and demand patterns”. TOP-002-2 R11 requires the Transmission Operator to perform a next day study. Thus, a Transmission Operator would have to include day-ahead interchange schedules in its next day study in order to plan to meet them. Then TOP-002-2 R10 requires the Transmission Operator to plan to operate within IROLs and SOLs.
Agree
 
Disagree
The NSRS "agrees" to the intent of the requirement and that no default procedure is necessary. The requirement language should remove the words "No more than one hour". Scheduled interchange may be agreed to prior to that first operating hour along with other hours of static MW flow, for example. If this previously agreed-upon interchange schedule has not changed, no further communication should be needed.
Disagree
 
Disagree
 
 
Individual
Dan Rochester
Independent Electricity System Operator
Agree
 
Agree
From a practical standpoint, we agree with this change on the basis that this does not conflict with the Functional Model. However, this may create a problem if and when an entity steps forward to register as the IA and perform the IA functions. We suggest the SDT consider reverting back to the existing applicability and assign this to the IA, but specifies that given there are no entities registered as the IA and the default is the sink BA, all BAs are required to perform the IA function and hence need to register as one.
Disagree
We do not agree that this defined term is necessary; the concept can be described in the purpose without creating a new definition. However, if the CI SDT decides to maintain this definition, we suggest the SDT coordinate the development of the Interchange Coordination definition with the Functional Model Working Group, which in its FM Version 5 has developed a definition for Interchange and Interchange Coordinator. Having different definitions for similar terms within the NERC documents tend to create confusions.
Disagree
Standards should be written to drive proper behaviors, not to specify the equipment and staff capabilities. The latter requirements belong to Organization Certification Requirements. Further, the term “desire to” is not needed as it makes the standard not measurable. Suggest removing it from R1 and R3.
Agree
 
Disagree
The SDT seems to have missed the distinction made in the original set of standards. INT-001 establishes the mandate that special case interchange be explicitly assigned to some entity. In the case of Inadvertent Interchange payback, such payback can be initiated by either BA that has an accumulation, but R2.2 clearly mandates that the responsibility falls on the sink BA. The SDT would be better served to raise the issue of whether or not Inadvertent Interchange is a reliability issue or a business issue. Where INT-001 relates to a single Interchange, INT-009 relates the sum of all Confirmed Interchange and to the fact that the net of Confirmed Interchange only goes into the ACE equation. These are two distinct functions. INT-009 recognizes that NET Interchange is done among adjacent BAs. INT-001 assigns responsibility to BAs that may or may not be adjacent.
Agree
 
Agree
We agree with the general approach of INT-006. With respect to the specific requirements of R1, we agree with R1.1, but we do not understand how R1.2, R1.3 and R1.4 apply to the general statement in R1 that is talking about distributing ‘a request’ within a minute of its receipt. For example, if the request has not yet been distributed – how can it have been denied (R1.4). We do not agree with R7.2, 7.3, 7.4. The general text of R7 is to require notification of ‘whether or not AI was transitioned to Confirmed. The language of R7.2 implies something has already been distributed, yet the purpose of R7 is the actual distribution. If 7.3 or 7.4 are true the notification should be that it WAS NOT transitioned to Confirmed. If the intent is to only require notification of AI that was confirmed, then the language of R7 needs to be modified to reflect that intent. INT-006 was designed to mandate the distribution of information. One could argue that there is a possibility that an IA would collect approvals/denials and not inform anyone of the results, and hence there is a need to mandate that the data be distributed. If one agrees that the data be distributed, one could argue that there is a need to define the time-frame. The NAESB Tables bound the analysis and response times. The Timing Tables in INT-006-3 create a window of 1 minute between when confirmations are mandated and when they are implemented. Given the fact that it takes some time to change the values going into a BA's ACE equation there is not a lot of time to allocate. The one-minute period is consistent with the Tables.
Agree
The reliability reasons for denying an interchange request should be provided.
Agree
 
Agree
The phrase ‘shall not transition an Arranged Interchange to Confirmed Interchange’ appropriately utilizes the currently defined terms, but it is not clear what action should be taken – should there be a transition to a state of denied?
Disagree
(1) Potentially required is not measurable (2) R8 is redundant with TOP-005-2 R2; and (3) R9 is redundant with IRO-001-1.1 R9 (all issues) & IRO-009-1 R3 (Day Ahead IROLs)& IRO-004-2 R1 (the BA must follow directives).
Disagree
(1) The requirement assumes that it defines the complete set of exemptions. However, the IRO and TOP standards do a better job by mandating that the RC and TOP take actions for IROLs not just during an event but also if an event is anticipated. (2) This requirement is redundant with IRO-009-1 R4
Disagree
The word "composite" is confusing. Does it mean the net BA to BA interchange or individual BA to BA interchange? The default when there is a disagreement is that the BAs must check each Interchange Schedule and not just Net Interchange.
 
Disagree
We are not aware of any conflicts.
General: There are several places where the Load Balancing Authority is used. Why is this term used instead of Sink Balancing Authority? INT-004: Please describe why an AI created for the based on the maximum MW value of a Dynamic Schedule should never need to be modified. This seems to allow everyone to put in a maximum value and leave unchanged for the duration of the interchange. INT-006: The term IA still exists in the timing tables. Also, the table requires distribution of Late and ATF AIs when the language in the requirements is only applicable to on-time AI. INT-009: The addition of the phrase ‘and maintain the generation-to-load balance’ does not seem to be consistent with the requirements of standards; there are no requirements related to this action. Suggest removing. INT-010: The purpose of INT-010 indications that some Interchange Schedules should be exempt from compliance with ‘other Interchange Standards’. The requirements within INT-010 do not seem to be consistent with this purpose. INT-011: The Reliability Coordinator is in the Applicability section but is not mentioned in the requirements