03/11/14 RECOMMENDATION

FLOWCHART AND TIMING

GOALS

• Finish going through the process flowchart listing the steps and various options for each. • Develop options (choices) for each step, such as

defender priority, ability to meet/exceed, match by changing start and/or stop date, etc. and give recommendation to each. • Develop a proposal on the sandbox (or

something like the presubmittal workspace) and develop the recommendation. This needs to be settled because a lot of issues/decisions will vary depending upon what we do here.

OPTIONS BEING DISCUSSED

• Options Being Discussed• Initial evaluation• Provider evaluation time limit• Queue protection• Matching evaluation timing• Matching evaluations• Challenger confirmation time limit• Challenger REBID• Binding the defender vs. Do no harm• Opt out flags• “Issues and Requirements for ROFR Defender

Assignment” worksheet

INITIAL EVALUATION

• The TP cannot continuously reevaluate a challenger based on changing conditions. The process must be initiated based on a given or initial evaluation. • In order to ensure the TP has time to evaluate and

initiate the P&C process a measure must be put into place to allow the TP to select an evaluation and disregard subsequent updates.

• Even in fully automated systems there is a delay between initiating an evaluation and initiating the P&C process. Changes to the defender set must be taken into account

INITIAL EVALUATIONA-DEFENDERS

• If A-Defenders change status during an evaluation then the challenger must be reevaluated.

• Option 1: Suspend customer action on identified A- defenders• Set the competing flag upon identification as an A-

defender. This will suspend customer initiated actions.• Offers the greatest simplicity and transparency• Can be applied consistently across ROFR and non-ROFR

scenarios

INITIAL EVALUATIONA-DEFENDERS (CONT.)

• Option 2: Allow SUPERSEDED to be performed from the CONFIRMED state. Applies only when an A-defender confirms after P&C has been initiated.• Requires a change to the state transition diagram• Introduces some complexity to the process• No deviation from normal TSR processing from the

customer standpoint• Could be seen as not honoring ROFR if an A-defender

confirms and would normally have ROFR

INITIAL EVALUATIONA-DEFENDERS (CONT.)

• Option 3: If the SUPERSEDED action is unsuccessful on any A-Defenders due to confirmation then reevaluate the challenger.• Requires a flowchart change to put SUPERSEDED before

accepting the challenger.• Open to the ‘clear the queue’ game

• Some embedded processing delay• No deviation from normal TSR processing from the

customer standpoint

INITIAL EVALUATIONFLOWCHART RECOMMENDATION

1. TP begins the evaluation process for a TSR that has been identified as a challenger.

2. TP captures the information required for evaluation. Subsequent system condition changes will not be required to be considered.

3. TP performs the evaluation of the challenger and sets the competing flag on the challenger and all defenders.

4. Prior to initiating P&C TP performs a final review to ensure all defenders remain valid and of the same type. If not then reevaluate the challenger. (Motion 84)

INITIAL EVALUATION MOTION 2

• Motion 2:“Once the list of Defenders needed to provide full

service to the challenger has been established, The TP shall not be required to perform any further evaluations of the challenger based on system conditions.”

INITIAL EVALUATION MOTION 3

• Motion 3:“When a TSR is identified as an A-Defender the

COMPETING_REQUEST_FLAG shall be set to ‘Y’. Customer initiated status changes shall not be permitted from a pending status when the COMPETING_REQUEST_FLAG is set. Once the preemption and /or competition has concluded the COMPETING_REQUEST_FLAG shall be set to ‘N’. Customer initiated status changes shall be permitted at this point.

Once the COMPETING_REQUEST_FLAG is set for all A-Defenders the Transmission Provider may perform a final review prior to initiating Preemption and Competition to ensure all defenders remain valid and of the same type. If all defenders are not valid and of the same type the Transmission Provider may perform a full reevaluation of the challenger.”

PROVIDER EVALUATION TIME LIMIT

• Once a competition has been initiated subsequently queued TSRs that impact the same time points and elements must wait for the pending competition to complete prior to being processed.

• This will force TPs to violate the Provider Evaluation Time Limit as defined in Table 4-2.

• Example:• Two Non-Firm Weekly TSRs are queued for the same path

and time frame. • The first TSR is identified as a challenger with weekly ROFR

defenders. Defenders have 24 hours to match.• TP has 4 hours to evaluate the second TSR.

PROVIDER EVALUATION TIME LIMITRECOMMENDATION

• Option 1: Do not start the clock on the Provider Evaluation Time Limit until all

pending competitions are complete• Requires modification to Table 4-2 footnote 1

• Option 2: Reduce Matching time limits as needed• Required reductions would be too severe

PROVIDER EVALUATION TIME LIMITMOTION 4

• Motion 4“If evaluation of a TSR is contingent on a pending

competition(s), Provider Evaluation Time Limit as defined in Table 4-2 shall not start until all pending competitions have completed.”

QUEUE PROTECTION

• Shorter term TSRs may be queued behind longer term TSRs based on the TP’s timing rules.

• If the longer term TSR enters into P&C this may cause undue delay in processing the shorter term TSR.

• Example:• A Non-Firm Weekly TSR is queued Monday at 16:00 with a

start time of 00:00 Wednesday. • NF Weekly enters into P&C. Defender has 24 hour Matching

time limit. TP has 4 hour evaluation time.• NF hourly TSRs queued Tuesday for Wednesday service will

not receive a response until after 20:00 Tuesday evening.

QUEUE PROTECTION RECOMMENDATION

• A general provision is needed that gives TPs the flexibility to account for this circumstance.• The provision must be limited enough to prevent abuse

but be broad enough to provide protections.

• The provision should apply to each challenger. There should not be a variance for each possible scenario.• The provision is best implemented using the

concept of challenger lead time.• Challenger lead time is the time in advance of start of

service a TSR must be QUEUED in order to qualify as a challenger. (Motion 79)

QUEUE PROTECTION MOTION 5

• Motion 5:• “The TP may extend a Non-Firm challenger’s

competition lead time to prevent the Preemption and Competition process from introducing undue delays in the timely processing of shorter term requests. This only applies when:• A shorter term request could be queued after a longer

term challenger• The longer term challenger could have ROFR defenders• The shorter term request could not otherwise be

processed until the longer term challenger’s competition is completed”

MATCHING EVALUATION TIMING

• The TP requires time to evaluate MATCHING requests as they are received. • Given that a defender may submit a Match at the last

moment, this time cannot be embedded in the MATCHING Response Time Limit• An additional column in Table 4-2 will be required• REBID response times were used as a basis for

discussion• No evaluations times were shortened. It is assumed

that all times were developed with good cause. MATCHING evaluation is more complex than REBID evaluation so it should take at least as long.

MATCHING EVALUATION TIMING RECOMMENDATION

• NF Hourly and Daily times were extended• Firm Monthly times

were based on 72 hour best effort from footnote 6• Superscript indicates

calendar days• Amendment to Motion

79 required

ServiceProvider Matching Evaluation Time Limit

NF Hourly 20 min

NF Daily 20 min

NF Weekly 4 hours

NF Monthly 2 days5

   

Firm Daily 4 hours

Firm Weekly 4 hours

Firm Monthly 3 days5

MATCHING EVALUATIONS

• A MATCHING request must be evaluated for validity by the TP upon receipt (QUEUED status)• This does not include an AFC/ATC or feasibility

evaluation• Feasibility cannot be guaranteed at this point as

subsequent higher priority MATCHING requests may be received

• The TP has already tested and communicated a minimum MATCHING profile for feasibility

• A final evaluation will be performed upon receipt of the final MATCHING response per Motion 58

MATCHING EVALUATIONS RECOMMENDATION

• Option 1: TP indicates validity of a MATCHING request by setting the status from QUEUED to RECEIVED or INVALID.

• Expanded use of the RECEIVED state to indicate that the request is being evaluated and that it has passed the validity check

• No new status or changes to the state transition diagram required

• Option 2: TP indicates validity of a MATCHING request by setting the status from

QUEUED/RECEIVED to VALID or INVALID.• Introduces the new status “VALID”• Increases transparency at the cost of complexity

MATCHING EVALUATION TIMING MOTION 6

“An additional column shall be added to Table 4-2 titled ‘Provider Matching Evaluation Time Limit’. This column shall indicate the time the TP has to respond to the validity of a Matching request. This column shall also indicate the time the TP has to perform all final Matching evaluations and communicate the results once the final Matching response has been

received.

• NF Hourly<1 hour – N/A• NF Hourly>1 hour–20

minutes• NF Daily – 20 minutes• NF Weekly – 4 hours• NF Monthly – 2 calendar

days• Firm Daily <24 hours – N/A• Firm Daily – 4 hours• Firm Weekly – 4 hours• Firm Monthly – 3 calendar

days”

Motion 6:

MATCHING EVALUATIONMOTION 7

• Motion 7:“There are two TP evaluations of MATCHING requests: one for

validity and one for feasibility as follows:• The Transmission Provider shall evaluate each MATCHING request

for validity upon receipt. The validity of a MATCHING request shall be indicated by setting the status from QUEUED to RECEIVED. Failure of the validity evaluation shall be indicated by setting the MATCHING request from QUEUED to INVALID. There shall be no requirement to include any AFC, ATC, or feasibility evaluations in this initial evaluation. This evaluation shall adhere to the Provider Matching Evaluation Time Limit which shall be populated in the template element MATCHING_RESPONSE_TIME_LIMIT.

• The final evaluation of preemption and competition with ROFR shall adhere to the Provider Matching Evaluation Time Limit which shall be populated in the template element RESPONSE_TIME_LIMIT.”

MATCHING EVALUATIONMOTION 79 AMENDMENT

• Motion 79 amendment:“The TP shall account for the Tier 2 Defender’s

Matching time limit, if applicable, the Challenger’s Confirmation time limit, and the Provider Matching Evaluation Time Limit when determining if the Preemption and Competition process should be initiated as follows…”

CHALLENGER CONFIRMATION TIME LIMIT

• When a TSR is issued a COUNTEROFFER they are given time to respond based on Table 4-2.• When a challenger is issued a COUNTEROFFER

there are additional concerns. • QUEUE processing delays• Defenders unsure of the final disposition of their request

• In order to mitigate these factors, challengers shall receive a modified confirmation time limit• By not opting out the challenger has agreed to

the modified time limit• An additional column in Table 4-2 will be required

CHALLENGER CONFIRMATION TIME LIMIT (CONT.)

• Firm times set to equal the matching confirmation time limit

• Footnote 2 will apply. • How will this be

handled for Coordinated Requests (footnotes 8 & 9)?

Service

Challenger ConfirmationTime Limit

NF Hourly 10 minNF Daily 1hourNF Weekly 2 hoursNF Monthly 24 hours   Firm Daily 24 hoursFirm Weekly

24 hours

Firm Monthly

24 hours

CHALLENGER CONFIRMATION TIME LIMIT MOTION 8

“An additional column shall be added to Table 4-2 titled ‘Challenger Confirmation Time Limit’. This column shall indicate the time a challenger has to respond (i.e. Confirm or Withdraw) the COUNTEROFFER status.

• NF Hourly <1 hour – N/A• NF Hourly >1 hour – 10

minutes• NF Daily – 1 hr• NF Weekly – 2 hr• NF Monthly – 24 hours• Firm Daily <24 hours – N/A• Firm Daily – 24 hours• Firm Weekly – 24 hours• Firm Monthly – 24 hours”

Motion 8:

CHALLENGER REBID

• The NT assignment recommended offering partial service to NITS challengers. The discussion held was based on the premise that NITS customer should either take the counteroffer or walk away

• There should be consistency in treatment of NITS and PTP challengers

• Option 1: Challenger REBID removes the challenger from P&C. An inventory only counteroffer will be offered.• Low complexity to implement and no timing implications• Concern is that this is not equitable treatment of customer options

CHALLENGER REBID (CONT.)

• Option 2: Reevaluate the challenger after REBID to determine the updated list of defenders and recommended actions• This seems to be the most equitable and consistent treatment of REBID• There are technical hurdles to implementation if the initial eval is used• Challenger may lose their status as a challenger if the initial eval is not

used• There are no timing implications due to existing standards for REBID

timing• This really comes down to a question of whether the implementation and

complexity is worth the value gained.

CHALLENGER REBID (CONT.)

• Option 3: Explore modification of Motion 20 • REBID requests can be processed normally• Minimum delay to queue• Is there any possible mitigation to the game Motion 20 was designed

to prevent?

• Option 4: Block the REBID status for all challengers• Set the competing flag upon identification as challenger. REBID will

not be allowed while the competing flag is set.• Low complexity to implement and no timing implications• Can be applied consistently across challengers of any tier

CHALLENGER REBID RECOMMENDATION

• Motion 20 will not be modified• Reevaluation is not recommended as it

introduces too much complexity• If a defender is dropped can they elect to keep their

match or remaining profile?• Is the provider required to modify the remaining and

matching profiles per motion 49? What if the defender has already elected a reduced remaining profile?

• Does the defender get a second chance to match?• Does the matching time limit reset?

• Option 4 was selected

CHALLENGER REBIDMOTION 9

• Motion 9:“When a TSR is identified as a challenger the

COMPETING_REQUEST_FLAG shall be set to ‘Y’. A status change from COUNTEROFFER to REBID shall not be permitted when the COMPETING_REQUEST_FLAG is set. Once the preemption and /or competition has concluded the COMPETING_REQUEST_FLAG shall be set to ‘N’.”

BINDING THE DEFENDERPRO-BINDING

• Modify Motion 20 such that final action may be taken on defenders prior to confirmation of challenger with ROFR

• Pros• This option offers the lowest complexity and greatest transparency• Pro-Binding resolves the question “Is it equitable that defenders that did not match

get the same unwinding benefit as defenders that did match?”• Eliminates the risk of repeated competitions since nothing changed if do no harm is

applied. • The game Motion 20 was put in place to prevent is partially mitigated due to

Defender option to match or walk away• Fast resolution to competition. Complete once all matching decisions are received.

BINDING THE DEFENDERPRO-BINDING(CONT.)

• Cons• This would result in defenders either losing service or taking additional

service while the challenger has no obligation to confirm.• The concept of ‘taking a lot to grant a little’ was addressed in Motion 47.

This must be addressed again as Motion 47 does not apply here. Defenders electing a low remaining profile may outweigh the requested extensions by defenders that elect to match.

• There is a lack of equity between challenger and defender as the challenger may walk away and the defenders are left in the same position as if the challenger had confirmed

• Potential conflict with Motion 36

BINDING THE CHALLENGER

• Do not allow a challenger to withdraw if only a counteroffer is available• This is similar to binding the defender as all parties are

locked into their decision. • Low complexity and fast• Addresses many of the problems present with binding

the defender

• The concept of forcing a customer to take any counteroffer was poorly received. It is also in direct conflict with Motion 17.

BINDING THE DEFENDERDO NO HARM

• Unwinding of P&C actions will be mandatory. Defenders do not get a choice to keep their match.

• This only applies where the challenger counteroffer > 0.• This only applies where the challenger withdraws a counteroffer.• The fundamental principal is that when the challenger is given

the option to walk away, no defenders should not be harmed if that option is elected.• If no counteroffer is available due to defenders exercising ROFR then do no

harm does not apply.

BINDING THE DEFENDERDO NO HARM (CONT.)

• Pros• Fully prevents the game Motion 20 was designed to prevent• No change to existing motions required• Provides equity to defenders vs. challengers• Timing impact is limited to specific condition

• Cons• More complex due to the need to undo sandbox actions and creation of an additional “path”

to completion of P&C.• Slower completion of P&C. Competition ends once challenger decisions has been made.

• There is a risk of repeated identical competitions as the unwind action effectively resets the conditions.• No mitigation will be developed. This is an acceptable risk.

BINDING VS. DO NO HARM RECOMMENDATION

• Binding the challenger will not be implemented. There is no support for forcing a customer to blindly accept all counteroffers.

• Binding the defender is the superior option from a process and development standpoint. It is the lowest complexity and fastest feasible option. It is fundamentally flawed in that it is fails to prevent gaming and/or disruption to service with no commitment.

• Do no harm was selected. The worst outcome of P&C is for CONFIRMED TSRs to lose service for no reason. The increase in complexity and extended timelines are an acceptable cost to prevent this outcome.

DO NO HARMMOTION 10

• Motion 10:“When there is a challenger with ROFR defenders

and:• One or more defenders exercise ROFR• The challenger receives a counteroffer >0 • The challenger sets the status to WITHDRAWN or the time

limit for confirmation has expired

All MATCHING requests shall be set to ANNULLED and all capacity withheld to accommodate the MATCHING requests shall be returned to AFC/ATC inventory. All COMPETING_REQUEST_FLAGs shall be set to ‘N’.”

OPT OUT FLAGS

• 2 flags• Opt-out from consideration as a challenger• Opt-out from identifying one’s own TSRs as defenders (Motion

62)

• Option 1• The opt out flag(s) will be a part of the transrequest template

and must be elected at the time of submission.

• Option 2• The opt out flag(s) will be available after the TSR is identified

as a challenger with ROFR defenders.

• Option 3• There should not be any opt out flags

OPT OUT FLAGSOPTION 1

• Option 1 The opt out flag(s) will be a part of the transrequest template and must be elected at the time of submission.

• Customers do not like having to opt out without detailed PC information. This is a complex decision that cannot be made up front. The sentiment is that it is important to have this decision available mid-stream after PC is identified.

• Changes will be needed for the transrequest and transstatus templates.

• This is a straightforward solution. Minimal complexity is added. There are no timing implications to consider.

OPT OUT FLAGSOPTION 2

• Option 2: The opt out flag(s) will be available after the TSR is identified as a challenger with ROFR defenders.

• This option provides customers with the most detailed PC information available.

• Customer notification must be sent once they are identified as a challenger with ROFR defenders. There would be a provider time limit for this notification.

• Notification should include what the COUNTEROFFER would be without P&C

• Concern that the challenger may get advance notice of ROFR if they are a defender as well

OPT OUT FLAGSOPTION 2 (CONT.)

• Customer will have some time to respond. The customer response will be embedded in the provider evaluation time limit (similar to REBID).• This will effectively reduce the

provider evaluation time limit by the time it takes the customer to respond.

• This will delay queue processing for the time it takes the customer to respond.

ServiceCustomer Opt out

NF Hourly 5 minNF Daily 5/10 minNF Weekly 1 hrNF Monthly 4 hr   Firm Daily <24 2 hrFirm Daily 2 hrFirm Weekly 2 hrFirm Monthly 4 hr*This is an example only

OPT OUT FLAGSOTHER OPTIONS

• Option 3: Explore modification of Motion 20. Challenger must be in final state prior

to taking actions on defenders.• Rejected due to gaming opportunities

• Option 4: The opt out flag(s) will be available after the TSR is identified as a challenger with ROFR defenders but not further

information will be provided.• Rejected as it is not substantially different from Option 1.

The customer still does not have the information to make an informed decision.

OPT OUT FLAGSRECOMMENDATION

• Option 1 is the recommended implementation for opt out flags.• This option was selected due its simplicity and

transparency.• Option 2 introduces substantial queue processing delays

and complexity. • The customer concern that they will not have enough

information at the time of submission remains.• All opt out flags will be disabled by default. That is a

customer must actively opt out of P&C rather than actively opt in to P&C.

OPT OUT FLAGSMOTION

Motion 1:“The transrequest template shall contain two flags that may be used to modify challenger rights. When set to ‘Y’ WAIVE_CHALLENGE shall waive all rights as a challenger. When set to ‘Y’ WAIVE_CUSTOMER_CHALLENGE shall waive all rights to challenge any TSR if the customer code of the potential defender is equal to the customer code of the submitted TSR. These flags shall be set to ‘N’ by default.”

WORKSHEET#1E

• #1e – “The valid Match has 0’s for the matching profile (see Motion 65) what status does the TP set to indicate that the remaining profile will be accepted. “

• The Transmission provider will set the Matching request to RECEIVED. It will be ACCEPTED/CONFIRMED once all responses have been received and evaluated.

WORKSHEET#3

• #3 – “Can a Matching request be REBID and/or WITHDRAWN? ”

• Matching requests are submitted preconfirmed. • All Matching requests are PTP• Matching requests are set to REFUSED or INVALID

for all evaluation failures• Neither status is possible given the conditions

and no exception should be made.

WORKSHEET#7

• #7 – “The Defender puts in a mitigating profile that exceeds the bounds of the maximum remaining profile, what is the correct TP action?”

• Committee agreed response:• “The Transmission Provider will set the matching request to

INVALID status”

• Motion 11:“If the customer submits a MATCHING request in which the

remaining profile of capacity over time exceeds the remaining profile provided by the TP, the TP shall respond by setting the MATCHING request status to INVALID.”

QUESTIONS?