Interim status report from the TP group
With Transmission Customer (TC)  Group Responses

Statement from the TP group: 
As a TP group we have not addressed all the issues in the parking lot and more time is needed to address all the issues to finalize. This is an interim report provided for discussion at the Task Force meeting on Monday April 26, 2010.
General Statement of Scope:
Develop an OASIS process to coordinate a defined group of requests (linked requests) across multiple systems.  

Additional TP scope-related comments:
1)	At a minimum this process should coordinate the  transmission  capacity associated with a Designated Network Resources (DNRs) request and an associated off-system Long-Term PTP requests.. TC agreed
2)	Note:  The TPs, while not mandating the process, recognize that this process’ complexity may range between extremes, such as:  TC Ok with a) Capacity True-up.
a)	 a simple approach which merely adds a capacity true-up option at the end of the current approval/confirmation process requiring TPs to accept customer-requested adjustments to confirmed requests in instances where at least one request could not be accommodated in full 
b)	a very rigorous process that accepts and processes a single multiple-system request which communicates with all impacted OASIS systems, receives responses from all impacted TPs (accept, counteroffer, denied, etc), communicates TP responses to the customer, and processes the counteroffer/rebid/coordination process for the multiple-system request until final state is achieved, and communicates the final state to impacted TPs and the customer. (duration and effort will be substantial)
3)	The scope of the NAESB process shall terminate once all of the defined group of requests are in a “coordinated” final state. TC expressed concern about ongoing service related to rollover rights.  Task Force response:  Scope will not terminate the process until the rollover rights status is known (if rollover rights are not granted, the linked requests may be terminated or adjusted via the true up).  Renewal requests to exercise rollover rights may be combined in a subsequent group of linked requests.  Scope will otherwise not include changes to the granting or management of rollover rights.  
Why is there a need to terminate linked or coordinated requests once they are in a “coordinated” final state?    Shouldn’t it be optional?  For future audit purposes, how will the TP know what was “coordinated” and what was not?  Task Force response:  The scope shall include audit functionality.
4)	The process should permit coordinated studies, in accordance with the pro-forma OATT, but it should not require performance of coordinated studies and it should not define the study process itself.  TPs feel that the existence of linked requests will improve their ability to correctly study their individual components of the request and will help them recognize opportunities for performing coordinated studies.  Lack of linkage between requests in the past made it difficult to determine which, if any, requests on adjacent systems should be studied together.  TC wants to ensure the shorter study performance should recognize the longer.
5)	The decision about what transactions can be combined may have consequences that are manifest in the complexity, implementation cost, and implementation date of the process.  
a)	The TPs feel that these decisions should preclude forcing TPs to:
i)	establish new products (e.g., should not require a TP to establish a heretofore optional product such as an “extended” product), TC OK.
ii)	accept a “coordinated state” which is not obtainable by other customers (e.g., require a weekly request to have different MW values for different days of the week if all other customers are required to profile a single MW value for each week) TC OK.
iii)	Monitor and react to requests on other OASIS systems, unless the process defines a mechanism that facilitates communication between OASIS systems such as in 2b above (e.g.,  assuming no such mechanism is defined and a requirement is established that requests must be of like increments, the TP should not be held in violation of a NAESB Business Practice for approving an hourly request that is “linked” to a daily request nor should a TP be held in violation of a NAESB Business Practice for not recognizing that a linked request has been confirmed on another OASIS system.) TC questions if this is result of 2a).   
Further clarification by TPs in response to Comments BG2 and JM3: This item was included so that TPs were not required to continually poll other TPs OASIS for the status of linked requests. The intent was to say that if the communication is needed (the 2a alternative currently contains a communication gap between TPs), it should be built into the NAESB Business Practice as a requirement.  The TPs were not trying to have control over what is deemed a violation. The TPs were trying to ensure that some mechanism is built into the Business Practice.
iv)	Validate consistency of product names and attributes.  TPs do not feel that consistency is mandated in the FERC orders and feel that attempts to maintain consistency may create market disruptions, (especially when attempting to validate consistency between market and non-market TPs).TC – could products/services with the same name have different attributes?  - could products/services with slightly different names have similar or same attributes?
TP response: There are defined products in the NAESB Business Practices. There is also a mechanism were a TP can define additional products and those products must be registered and defined in the TSIN registry. To the extent a NAESB-defined product is used there should be consistency. To the extent a TP-defined product is used, there is likelihood of inconsistency. Additionally, TPs are not required to use all NAESB-defined products (e.g. sliding, extended). For example, there will be inconsistency of duration if a fixed product is linked to an extended product. TPs are not in favor of doing a validation on the consistency of the linked product names and/or attributes. For example, TPs were trying to avoid validation that would prohibit a fixed product being linked to an extended product. 
Consensus 5/19/2010: In addition to the routine validation done all requests, each TP will be limited to performing validation that the product requested on the TP’s system is an allowable “linked” product (e.g. monthly, yearly).
b)	TPs prefer that linked short term requests be pre-confirmed on all OASIS systems.  This removes questions about whether a pre-confirmed request on one system should lose pre-confirmation priority because another component of the linked request (on another system) is not pre-confirmed.  TC – How would this work if one system only allows partial?  How do adjust for that occurrence?  Pre-confirm should only be valid if accepted in full on all systems.
TP Response 5/19/2010: Current rules prohibit withdrawal of a pre-confirmed request. On a given TP’s system the current Business Practices (note: need citation to current standard – WEQ-001-4.9.1) state that if a pre-confirmed request is counteroffered, the pre-confirmation flag is removed allowing the TC to withdraw the request. Additionally, pre-confirmation priority only applies to short term point to point requests. The TPs are concerned that if one of the linked requests is pre-confirmed and another part of the linked request is not pre-confirmed, what happens if the not pre-confirmed request is withdrawn?
The Task Force considered a requirement that, at the TC’s discretion, in any given linked request, all linked short term point to point requests must be pre-confirmed or none can be pre-confirmed. However, because this would require that the each TP has sufficient information to validate that each leg has been pre-confirmed (meaning, each TP would have to go onto the other TPs’ OASIS system and validate the pre-confirmation status), it was determined not to include this requirement.
Tentative Consensus 5/19/2010:  Pre-confirmation is required for short term point to point requests and the final true-up will allow any adjustments that were made on one link (through a counteroffer, rebid or denial) to be made on the other links (true-up mechanism has not been determined; therefore, how the adjustments to the linked requests will be made has not been determined – it most likely will be via a customer-initiated process).
c)	The TPs recognize that many of the decisions in this vein must focus on “fairness” issues, which are more appropriately addressed by customers.  Fairness issues encompass both the impact on ATC offerings as well as the impact of “gaming” the process.  Examples are:
i)	If the process requires all TPs to respond to their respective components of the linked request before a customer is required to take action such as in 2b above (effectively extending customer response time until all responses are known) then queue processing of subsequent requests will likely be delayed on constrained interfaces and may result in unreserved ATC.  Are delays in queue processing acceptable in all instances, particularly in timeframes which are heavily congested?  TC – unsure if all instances are acceptable, but  generally agree with delay.
ii)	If the process permits current queue processing by each TP individually with a true-up mechanism at the end such as in 2a above, there will be instances where a TP denies a request that was queued subsequent to the linked request because the TPs component of the linked request was confirmed in full and then, at the true-up time, reduces the confirmed linked request’s capacity and offers the amount reduced as additional ATC.  In this instance the queue processing is not delayed but the customer who was denied capacity has lost his queue position (refused for insufficient ATC) and must submit a new request to compete for the newly posted ATC.  TC – generally OK.  Is there any other recourse? 
5/19/2010 TP response: The recourse may be the hybrid option discussed later in the document where nothing gets confirmed until all are accepted.  
5/19/2010 TP response to BG5: Adding a new status of “provisionally denied” for the 2nd customer’s request may “open a can of worms”. For example, customers may want to have a “provisionally denied” in the hopes that another customer may redirect off the requested path.
Discussion deferred to “exploder discussion”. Barry will send out the first correspondence.
iii)	If the process permits long-term firm requests to be linked with short-term requests then gaming may occur wherein a customer submits a linked request knowing that the long-term firm request may be withdrawn at any time.  This would permit customers to withhold firm ATC from the market on multiple interfaces without the obligation to consummate the transaction. TC – If short term were pre-confirmed, gaming issue is moot.
iv)	Similarly, if pre-confirmation were not required, customers may game the system by withholding ATC from the market while retaining the option to withdraw at any time. TC – See (iii).
6)	Queue processing is a difficult issue.  TPs recognize the following three scenarios, each of which is dependent on the Business Practices’ complexity (see item 2).  Assuming the Business Practice establishes procedures to facilitate the processing of requests across OASIS systems (provides mechanisms for performing all required checks and balances) the differences are primarily “fairness” issues which need to be addressed by customers. TPs also recognize that flexibility may be needed in this arena. (e.g., Scenario 2 is similar to the processing done in WestTrans and is possible because all of these transmission providers use the same OASIS vendor.  The final Business Practice Standard should not preclude use of this scenario.)  Additional scenarios may be identified as the scope is more clearly defined.
a)	Scenario 1: Independent TP responses with true-up – In this scenario, requests are made on each OASIS system with some unique identifier on each that establishes the link (similar to the Tag Code which ties schedule components across multiple systems for e-tagging) and each TP will evaluate and respond to the request on its OASIS as if it were not linked.  After all requests have been processed, a true-up procedure would be incorporated to permit the customer to align capacity across all requests.  Queue submission and response timing would be the same as if the request were not part of a linked request.  Study timing and creditworthiness/deposits would be processed as if the request were not part of a linked request.  Upon completion of the true-up, some reservations may be annulled (full release of commitment to purchase transmission capacity) or recalled (partial release of commitment to purchase transmission capacity) and the agreement and corresponding deposit amount would be finalized/amended  TC – If study timing not changed, how are they linked?.
5/19/2010 TP Response: 
­	TPs envisioning some sort of new template field(s) to indicate the linking.
­	To JM6 – The TPs did not state that the true-up had to be to the same MW value. The TPs do propose later on that the customer has the option on the MW value during the true-up.
­	Response times will be based on the current response time based on product. The true-up process will occur immediately after all requests are at their “pre-true-up final state”.
b)	Scenario 2: Single request submittal – In this scenario, a customer would submit a single request, similar to e-tag submittal, which would request transmission capacity on multiple systems. Under this scenario, it would be possible to establish a single queue time which corresponds to the request submittal time.  TPs would evaluate and respond to requests based on their product characteristics (Table 4-2).  Customer acceptance (confirm/rebid) would not be permitted until all TPs have responded.  Once TPs have responded, the Customer would have to respond to the single request in the shortest timeframe of the requested components (Table 4-2).  For example, if the request asked for a yearly product on one system and a monthly product on another system, the customer would have to respond to the whole request as required in Table 4-2 for the monthly product. All agreements and deposits would be established once final state is reached.  TC – Agreed.
5-19-2010 Consensus – Task Force will recommend not pursuing this option at this time because of the complexity and potential significant OASIS-related changes that might be needed.
c)	Scenario 3: Multiple requests with single response – This scenario is a hybrid of Scenario 1 and Scenario 2.  In this scenario, requests are made on each OASIS with some unique identifier, TPs would evaluate as if the requests were not linked, but customer acceptance would not be permitted until all TPs have responded.  In this scenario, the queue time for all requests would need to be set equal to the queue time of the last queued request (e.g., if three monthly requests are submitted over three days, the queue time for each of the requests would be set equal to the submittal time of the request that was submitted on day 3).  TP response times (Table 4-2) would be relative to this queue time.  Customer response, as in Scenario 2, would be associated with the shortest timeframe of the requested components.  All agreements and deposits would be established once final state is reached.  TC – Hybrid? Does this mean “all providers indicate ACCEPTED status before TC must confirm?”
5/29/2010: This could be a viable option. Further discussion by the Task Force on OASIS functionality impacts and confirmation timing table impacts is needed. Scenario 3 needs to be permitted because this is what is used by wesTTrans.
7)	When at least one TP cannot accommodate the requested capacity allocation (counteroffer), the TPs prefer that customers decide what capacity should be allocated to the remaining requests (or components of a single request).  Customer decisions include factors such as whether or not the customer will be purchasing losses or supplying losses, etc.  If Scenario 1 (Item 6.a) is incorporated, the TPs believe the true-up decision should be communicated to all impacted TPs within the timeframe allotted in Table 4-2 for the customer to respond to the last request processed. For example, if the last request processed is a monthly firm request, then the customer must communicate any true-up requirements to all TPs within 4 days of TP’s acceptance or counteroffer of that request.  TC – Agreed.
8)	TPs prefer the simplicity of one denial (denial of full capacity, not a counteroffer) means that all linked requests are denied and believe this is consistent with FERC’s expectation that linked requests be treated as a “single request”. This is included in the current WestTrans process. However, TPs recognize that if this is to be enforced by TPs then NAESB needs to provide a mechanism for communicating the denial to all impacted TPs.  There is a mechanism for communicating changes in status to customers but not a mechanism for communicating status to other OASIS systems.  TPs do not want to burden the OASIS systems by having to continually poll other systems to ascertain request statuses of linked requests. Such a polling requirement could appreciably slow all OASIS system processing times for all OASIS users.  TC – Agreed, although  providers communicate at some level today. TPs are required to coordinate data for ATC to comply with NERC standards. 
9)	Coordination of requests across multiple time zones is not a new issue.  However, when a network customer who is requesting a DNR must show firm transmission capacity on a system in a different time zone, a timing mismatch may occur.  Some TPs offer fixed products (midnight to midnight), but have the option of offering sliding and extended products.  This new NAESB business practice should not require offering of additional products in order to establish an identical hour-by-hour match of reservations on OASIS systems that serve different time zones.  It should, however, establish a prohibition on denial of a DNR because of a time-zone induced hour-by-hour mismatch.  The OASIS subcommittee may also wish to review and modify the definitions of “fixed”, “sliding” and “extended” in order to permit TPs to offer narrowly defined products that accommodate time-zone specific products.  TC – Agreed, as long as other system’s do not require sync’ed Point-to-Point and DNR requests (matching time zones). TC’s should not be forced to procure an additional one hour of transmission service on a non-firm basis (since not all TP’s offer firm hourly product and not all TPs offer short-term firm in all future periods) to transfer a firm energy source for which it has long-term firm arrangements thus putting the firmness of the transaction at risk for that beginning/ending hour.
10)	On a constrained interface for instances where a the linked request triggers a Right-of-First Refusal (ROFR) offering to an existing holder of transmission capacity, the process should accommodate the process timing to work through the ROFR process (extend response time).  In a similar vein, if a customer with a linked request, after confirmation of all requests (and after true-up if included in the process), is subject to competition (Table 4-3) on one OASIS system, the outcome of that competition should be no impact on the statuses of the remaining components of the linked requests .  That is, loss of one component of a confirmed linked request does not invalidate the remaining components of the linked requests, nor does the extension of one component of a linked request via a matching request give the customer the right to request extended capacity on the remaining components of the linked request.  TC – Doesn’t this example show a continuation of today’s issues?  ROFR should not invalidate our linked requests.

TABLE 4-2 REQUEST TIMING REQUIREMENTS 	
Class 	Service Increment 	Time QUEUED Prior to Start 	Provider Evaluation Time Limit1 	Customer Confirmation Time Limit2 after ACCEPTED or COUNTEROFFER3 	Provider Counter Time Limit after REBID4 	
Non-Firm 	Hourly 	<1 hour 	Best effort 	5 minutes 	5 minutes 	
Non-Firm 	Hourly 	>1 hour 	30 minutes 	5 minutes 	5 minutes 	
Non-Firm 	Hourly 	Day ahead 	30 minutes 	30 minutes 	10 minutes 	
Non-Firm 	Daily 	N/A 	30 minutes 	2 hours 	10 minutes 	
Non-Firm 	Weekly 	N/A 	4 hours 	24 hours 	4 hours 	
Non-Firm 	Monthly 	N/A 	2 days 5 	24 hours 	4 hours 	
						
Firm 	Daily 	< 24 hours 	Best effort 	2 hours 	30 minutes 	
Firm 	Daily 	N/A 	30 days6 	24 hours 	4 hours 	
Firm 	Weekly 	N/A 	30 days6 	48 hours 	4 hours 	
Firm 	Monthly 	N/A 	30 days6 	4 days 	4 hours 	
Firm 	Yearly 	60 days 7 	30 days 	15 days 	4 hours 	
Notes for Table 4-2: 
1 Consistent with regulations and filed tariffs, measurement starts at the time the request is QUEUED.
2 Confirmation time limits are not to be interpreted to extend scheduling deadlines or to override pre-exemption deadlines.
3 Measurement starts at the time the request is first moved to either ACCEPTED or COUNTEROFFER. The time limit does not reset on subsequent changes of state.
4 Measurement starts at the time the Transmission Customer changes the state to REBID. The measurement resets each time the request is changed to REBID.
5 Days are defined as calendar days.
6 Subject to expedited time requirements of Section 17.1 of the pro forma tariff. Transmission Providers shall make best efforts to respond within 72 hours, or prior to the scheduling deadline, whichever is earlier, to a request for Daily Firm Service received during period 2-30 days ahead of the service start time.
7 Subject to Section 17.1 of the pro forma tariff, whenever feasible and on a
nondiscriminatory basis, Transmission Providers should accommodate
requests made with less than 60 days notice.	

Table 4-3
Priorities for Competing Reservation Requests

ROW	Request or Reservation 1	Is Preempted by Subsequent Request 2	Right of First Refusal?	
1	Tier 1:  Long-term Firm, Native Load, and Network Firm	N/A - Not preempted by a subsequent request.	N/A	
2	Tier 2:  Pending (not confirmed) or confirmed but conditional Short-term Firm	Tier 1:  Long-term Firm, Native Load, and Network Firm, 

Once Request 1 is unconditional, it may not be preempted.	No	
3a	Tier 2: Pending, pre-confirmed Short-term Firm	Tier 2: Pre-confirmed Short-term Firm of higher service increment. 	No	
3b	Tier 2: Pending, pre-confirmed Short-term Firm	Tier 2: Pre-confirmed Short-term Firm for the same service increment but of longer duration1	No	
3c	Tier 2: Pending pre-confirmed Short-term Firm	Tier 2: Pre-confirmed Short-term Firm for the same service increment, equal duration1 but higher price	No	
3d	Tier 2: Pending, not pre-confirmed Short-term Firm	Tier 2: Pre-confirmed Short-term Firm of higher service increment	No	
3e	Tier 2: Pending, not pre-confirmed Short-term Firm	Tier 2: Pre-confirmed Short-term Firm for the same service increment and of equal or longer duration1	No	
3f	Tier 2:  Confirmed but conditional2  Short-term Firm	Tier 2: Pre-confirmed Short-term Firm of higher service increment	Yes	
3g	Tier 2:  Confirmed but conditional2  Short-term Firm	Tier 2: Pre-confirmed Short-term Firm for the same service increment but of longer duration1	Yes	
3h	Tier 2:  Confirmed but conditional2  Short-term Firm	Tier 2:  Pre-confirmed Short-term Firm for the same service increment, equal duration1 but higher price.	Yes
	
4	Tier 3:  Network Service From Non-Designated Resources	Tiers 1 and 2:  All Firm (including Network).	No	
5	Tier 4:  All Non-Firm PTP	Tiers 1 and 2:  All Firm (including Network).	No	
6	Tier 4:  All Non-Firm PTP	Tier 3:  Network Service from Non-Designated Resources.	No	
7	RESERVED			
7a	Tier 4: Pending, pre-confirmed Non-firm	Tier 4: Pre-confirmed Non-firm of higher service increment. 	No	
7b	Tier 4: Pending, pre-confirmed Non-firm	Tier 4: Pre-confirmed Non-firm for the same service increment but of longer duration1	No	
7c	Tier 4: Pending, pre-confirmed Non-firm	Tier 4: Pre-confirmed Non-firm for the same service increment, equal duration but higher price	No 	
7d	Tier 4: Pending, not pre-confirmed Non-firm	Tier 4: Pre-confirmed Non-firm of higher service increment	No	
7e	Tier 4: Pending, not pre-confirmed Non-firm	Tier 4: Pre-confirmed Non-firm for the same service increment and of equal or longer duration1	No	
7f	Tier 4: Pending, not pre-confirmed Non-firm	Tier 4: Pre-confirmed Non-firm for the same service increment, equal duration but higher price	No 	
7g	Tier 4:  Confirmed Non-firm more than one hour before start of service 	Tier 4: Pre-confirmed Non-firm of higher service increment
	Yes	
7h	Tier 4:  Confirmed Non-firm more than one hour before start of service	Tier 4: Pre-confirmed Non-firm for the same service increment but of longer duration1	Yes	
8	RESERVED			
9	Tier 5: Non-firm PTP Service over secondary receipt and delivery points.	Tiers 1 through 4	No	
10	Tier 6: Non-firm Next Hour Market Service	Tiers 1 through 5	No	

Notes for Table 4-3:

1	Longer duration means more multiples of the same SERVICE_INCREMENT in a single request.  Each such multiple must be at the same level of capacity. For example, a single request for three consecutive days shall be considered longer duration than a single request for two consecutive days.  Also, multiple service requests or reservations may not be grouped for the purpose of determining duration.  For example, three separate one-day requests for three consecutive days of service shall not be considered longer duration than a single request for two consecutive days. 
2	Short term reservations that are conditional as defined in Section 13.2 of the pro forma tariff.

11) Linked request across multiple systems where one of more of the requests is a DNR/PTP concomitant request
	1. See item 4 above involving studies
	2. Should not release the capacity for undesignated DNR until the “coordinated” final state capacity is determined (see item 3). If the DNR/PTP concomitant request is confirmed prior to knowing “coordinated” final state capacity and firm capacity associated with the undesignated DNR has been released and then the released DNR capacity might not be available for reinstatement at true up time. 
12) Redirect 
1) Firm redirect under scenario 1 
Example: Two 200 MW requests are linked and BP is permit each TP to process and have a true-up at the end.  One of the requests is a Firm Redirect and it is accepted and confirmed before a response has been received for the second request.  The TP for the first request releases 200 Mw on the parent path.  The TP for the second request can only accommodate 75 Mw.  Under this scenario, the Redirect capacity can be lowered to 75 Mw but it will not be possible to reinstate the additional 125 Mw to the parent path.  This should be no different than the discussion regarding partial ACCEPTED and should not allow release of any capacity until the entire path is ACCEPTED in full or, due to a COUNTEROFFER (which would allow the linked transmission to be reduced as well), is accepted at a lesser value.