38884 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

1Open Access Same-Time Information System

and Standards of Conduct, Order No. 889, FERC

Stats. & Regs. ¶31,035, 61 FR 21,737 (1996); order

granting request for clarification, 77 FERC ¶ 61,335

(1996); order on reh’g, Order No. 889–A, FERC

Stats. & Regs. ¶31,049, 62 FR 12484 (1997); and

order denying reh’g, Order No. 889–B, 81 FERC

¶ 61,253, 62 FR 64715 (1997).

See also Promoting Wholesale Competition

Through Open Access Non-Discriminatory

Transmission Services by Public Utilities; Recovery

of Stranded Costs by Public Utilities and

Transmitting Utilities, Order No. 888, FERC Stats.

& Regs. ¶ 31,036, 61 FR 21540 (1996); order on

DEPARTMENT OF ENERGY

Federal Energy Regulatory

Commission

18 CFR Part 37

[Docket No. RM95–9–003]

Open Access Same-Time Information

System and Standards of Conduct

Issued June 18, 1998.

AGENCY: Federal Energy Regulatory

Commission.

ACTION: Order on OASIS-related issues.

SUMMARY: In this order, the Federal

Energy Regulatory Commission (the

Commission): finds that ‘‘source and

sink’’ information must be unmasked at

the time when a transmission provider

updates the transmission reservation

posting to show the customer’s

confirmation that it wishes to finalize a

transaction; implements interim

procedures for the on-line negotiation of

transmission service price discounts;

and adopts a comprehensive update of

the OASIS Standards and

Communications Protocols Document

that implements a number of findings

made by the Commission in Order No.

889–A and in response to industry

suggestions.

DATES: The current S&CP Document

(Version 1.1), as modified to incorporate

the interim procedures on price

negotiation, is to become effective on

September 18, 1998. The revised S&CP

Document (Version 1.2) is to become

effective on December 1, 1998. The

revisions to the S&CP Document in

§ 4.3.7.b, pertaining to the masking of

source and sink information, are to

become effective on January 1, 1999.

FOR FURTHER INFORMATION CONTACT:

Marvin Rosenberg (Technical

Information), Office of Economic

Policy, Federal Energy Regulatory

Commission, 888 First Street, N.E.,

Washington, D.C. 20426, (202) 208–

1283

William C. Booth (Technical

Information), Office of Electric Power

Regulation, Federal Energy Regulatory

Commission, 888 First Street, N.E.,

Washington, D.C. 20426, (202) 208–

0849

Gary D. Cohen (Legal Information),

Office of the General Counsel, Federal

Energy Regulatory Commission, 888

First Street, N.E., Washington, D.C.

20426, (202) 208–0321

SUPPLEMENTARY INFORMATION: In

addition to publishing the full text of

this document in the Federal Register,

the Commission also provides all

interested persons an opportunity to

inspect or copy the contents of this

document during normal business hours

in the Public Reference Room at 888

First Street, N.E., Room 2A,

Washington, D.C. 20426.

The Commission Issuance Posting

System (CIPS) provides access to the

texts of formal documents issued by the

Commission. CIPS can be accessed via

Internet through FERC’s Homepage

(http://www.ferc.fed.us) using the CIPS

Link or the Energy Information Online

icon. The full text of this document will

be available on CIPS in ASCII and

WordPerfect 6.1 format. CIPS is also

available through the Commission’s

electronic bulletin board service at no

charge to the user and may be accessed

using a personal computer with a

modem by dialing 202–208–1397, if

dialing locally, or 1–800–856–3920, if

dialing long distance. To access CIPS,

set your communications software to

19200, 14400, 12000, 9600, 7200, 4800,

2400, or 1200 bps, full duplex, no

parity, 8 data bits and 1 stop bit. User

assistance is available at 202–208–2474

or by E-mail to

CipsMaster@FERC.fed.us.

This document is also available

through the Commission’s Records and

Information Management System

(RIMS), an electronic storage and

retrieval system of documents submitted

to and issued by the Commission after

November 16, 1981. Documents from

November 1995 to the present can be

viewed and printed. RIMS is available

in the Public Reference Room or

remotely via Internet through FERC’s

Homepage using the RIMS link or the

Energy Information Online icon. User

assistance is available at 202–208–2222,

or by E-mail to

RimsMaster@FERC.fed.us.

Finally, the complete text on diskette

in WordPerfect format may be

purchased from the Commission’s copy

contractor, La Dorn System Corporation.

La Dorn Systems Corporation is located

in the Public Reference Room at 888

First Street, N.E., Washington, D.C.

20426.

Table of Contents

I. Background

II. Discussion

A. Overview

B. Masking of Source and Sink Related

Information

1. Business Sensitivity and Competitive

Effect

2. Other Information Sources and the Need

for Source and Sink Information

3. Differing Impacts on Contract Path and

Flow-Based Transmission Pricing

Regimes

C. Proposed Interim Procedures to Achieve

On-Line Price Negotiation and

Disclosure of Discounts in Phase I OASIS

until Phase IA Changes Are Implemented

D. How Group Proposals to Revise the

S&CP Document

1. Comments on Preconfirmed

Reservations

2. Comments on Linking Ancillary and

Transmission Services

3. Comments on Capacity Profiles

4. Comments on Posting of Losses

5. Revisions to Phase IA S&CP Document

Recommended by the How Group and

the Commercial Practices Group

E. Other Proposed Revisions to the S&CP

Document

1. Comments on Standardized Naming of

Transmission Paths

2. Comments on Reservation Templates

3. Comments on Dynamic Notification of

Secondary Providers

4. Comments on Reservation Time Limits

F. Data Elements in the Templates Are to

be Fixed in Sequence and Number, and

Are Not to Differ Among OASIS Nodes

G. The Meaning of Disclosure of a

‘‘Discount Given to Particular Customer’’

H. Date of Implementation for Phase IA

Changes

I. Impact of Phase IA Implementation

J. Uniform Formats for Organizational

Charts and Job Descriptions

III. Effective Date and Congressional

Notification

Attachment 1—ABBREVIATIONS OF

NAMES USED IN ORDER

Attachment 2—Revised ‘‘STANDARDS AND

COMMUNICATION PROTOCOLS FOR

OPEN ACCESS SAME-TIME

INFORMATION SYSTEM (OASIS) Phase

IA’’ (clean version)

Attachment 3—Revised ‘‘STANDARDS AND

COMMUNICATION PROTOCOLS FOR

OPEN ACCESS SAME-TIME

INFORMATION SYSTEM (OASIS) Phase

IA’’ (with revisions to OASIS How

Group’s most recent submittal

highlighted)

Before Commissioners: James J.

Hoecker, Chairman; Vicky A. Bailey,

William L. Massey, Linda Breathitt,

and Curt He ́bert, Jr.

Order on OASIS-Related Issues

I. Background

The Commission has determined that

open access non-discriminatory

transmission service requires that

information about the transmission

system must be made available to all

transmission users at the same time by

way of the Open Access Same-Time

Information System (OASIS).1 The
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38885

reh’g, Order No. 888–A, FERC Stats. & Regs.

¶ 31,048, 62 FR 12274, 62 FR 64688 (1997); order

on reh’g, Order No. 888–B, 81 FERC ¶ 61,248

(1997); and order on reh’g, Order No. 888–C, 82

FERC ¶ 61,046 (1998).

2The term ‘‘Transmission Provider’’ is defined at

§ 37.3(a) of the Commission’s OASIS regulations, 18

CFR Part 37 (1997), as:

‘‘any public utility that owns, operates, or

controls facilities used for the transmission of

electric energy in interstate commerce.’’

3Early work on OASIS development has focused

on facilitating the more frequently sought short

term point-to-point transmission related services.

Phase I of OASIS development has involved the

establishment of basic OASIS sites (nodes) by each

transmission provider, by January 3, 1997, with

ongoing refinements that permit potential

transmission customers to reserve transmission

capacity and related services. OASIS Phase II

contemplates fully functional OASIS nodes that

additionally will allow on-line scheduling of

transmission service and of the energy associated

with transmission service that now must be

accomplished off-OASIS by facsimile or telephone.

4A list of the abbreviations of names used in this

order is provided in Attachment 1.

5Section 37.5(b)(2) of the OASIS regulations, 18

CFR 37.5(b)(2) (1997), requires that each

transmission provider operate its OASIS node in

compliance with the standardized procedures

specified in the OASIS Standards and

Communications Protocols document (referred to

herein as the S&CP Document).

6 In Order No. 889–A, we directed a number of

changes to OASIS that are listed at note 64, infra.

The submittals from the How Group included

responses to the directives in Order No. 889–A, as

well as requests for clarification and suggestions for

additional changes to the S&CP Document based on

business experience under OASIS.

7The minor revisions involved corrections of

examples, typographical errors, out-of-date cross

references, and similar changes.

8Consistent with this finding, we made a request

to the How Group to make recommendations on

eliminating any references in the S&CP Document

(Version 1.1) pertaining to masking the identities of

parties to the transmission transaction (e.g., at

§ 4.3.7.b). We also made a request to the How Group

to make recommendations on revising the templates

used for the posted transmission service offerings

(at § 4.3.2), the status of transmission service

requests (at § 4.3.7), and the status of ancillary

service requests (at § 4.3.9) to include: (1) the

transmission provider’s transmission and ancillary

services maximum (ceiling) rates; (2) the

transmission provider’s offering price; (3) the price

requested by the customer; and (4) the details of the

negotiated transaction. See Order No. 889–A, FERC

Stats. & Regs. ¶ 31,049 at 30,568.

9As we explain further below, depending on the

requirements of the transmission provider, source

and sink information, specifying the location of the

generator(s) and the location of the ultimate load,

may either refer to control areas in which the

generation or load are located, or to specific

generator or load busses.

10The relevant and now deleted OASIS

regulations, at §§ 37.6(e)(1)(iii) and 37.6(e)(3)(i),

respectively, read:

‘‘The identify of the parties will be masked—if

requested—during the negotiating period and for 30

days from the date when the request was accepted,

denied or withdrawn.

When any transaction is curtailed or interrupted,

the curtailment or interruption must be posted

(with the identities of the parties masked as

required in § 37.6(e)(1)(iii)) and must state the

reason why the transaction could not be continued

or completed. ’’

11Comments on the June 27, 1997 letter were

filed by APPA, CILCO, CCEM, Commonwealth

Edison, CPEX, Electric Clearinghouse (jointly with

PECO Energy), EPSA, Florida Power Corp, NRECA,

NYSEG, PJM, and Southern (on behalf of Alabama

Power, Georgia Power, Gulf Power, Mississippi

Power, and Savannah). The How Group also filed

comments, on September 22, 1997, which included

proposed revisions to the S&CP Document to

accommodate its proposed interim procedures for

on-line transmission service negotiations and the

posting of transmission price discounts.

12The How Group submitted a preliminary draft

version of this proposal on July 9, 1997. Further

additions, clarifications and corrections to the

August 12, 1997 filing, were submitted on

September 23, 1997.

current Phase I OASIS is an Internetbased electronic communication and

reservation system through which

transmission providers 2 furnish

potential transmission customers with

information pertaining to the

availability and price of transmission

and ancillary services and potential

customers may select and procure those

services in the form of service

reservations.3 To ensure that individual

OASIS nodes present information in a

consistent and uniform manner, the

Commission has relied upon the

industry to develop standards and

protocols for the Commission’s review

and approval that specify, among other

things, OASIS templates defining the

information that must be presented to

customers interested in procuring

transmission-related services, both in

the interactive form of graphical

displays or screens, and in the form of

downloadable files. To this end, EPRI

and NERC have jointly facilitated the

ongoing activities of the OASIS ‘‘How’’

Working Group (How Group) 4 to

develop suitable OASIS standards and

communications protocols.5 In this

order, we address several OASIS matters

raised in connection with our directives

in Order No. 889–A, various submittals

from the How Group, and comments

from interested persons.6

In Order No. 889–A, we determined

that any ‘‘negotiation’’ between a

transmission provider and a potential

transmission customer over price

discounts should take place on the

OASIS, visible to all market

participants. We also ordered some

minor revisions to the OASIS

regulations,7 and requested that the

How Group recommend certain changes

to the S&CP Document consistent with

the determinations we made in Order

No. 888–A.8 We made a request to the

How Group to propose any conforming

changes that might be necessary to the

S&CP Document by June 2, 1997, and to

inform the Commission of the earliest

date by which the industry could meet

our transmission service negotiation and

price discount disclosure requirements

during Phase I.

On June 27, 1997, the How Group

proposed interim measures to allow online transmission service negotiation

and posting of price discounts on

currently configured Phase I OASIS

nodes pending development of a more

satisfactory method.

The How Group also sought

clarification of the Commission’s stated

intention regarding source and sink 9

disclosure in Order No. 889–A. In that

order, we deleted from the OASIS

regulations provisions permitting

transmission customers to request that

transmission providers posting

transmission and ancillary service

requests and responses under § 37.6(e)

temporarily mask the identities of the

parties to the transaction during and

after negotiations for transmission

service.10 The How Group asked if this

meant that the source and sink

information routinely provided by

potential transmission customers and

reported on OASIS transmission service

request templates was also to be

divulged. In addition, the How Group

requested clarification as to whether a

transmission price ‘‘discount’’ as used

in Order No. 889–A refers to any price

below the ceiling price.

On July 15, 1997, we issued a notice

concerning the How Group’s June 27

filing and invited public comment on

the request for clarification of the

Commission’s masking requirements,

the proposed interim measures for online transmission service negotiations,

and the posting of transmission price

discounts. The 13 comments we

received are referred to herein as

‘‘Comments on How Group’s June 27

letter’’.11

On August 12, 1997, the How Group

submitted an updated revised S&CP

Document (Phase IA S&CP Document)

to fully implement our transmission

price discount negotiation policy and

the minor revisions enumerated in

Order No. 889–A.12 In addition to

replacing the How Group’s interim

measures with more comprehensive

procedures, the Phase IA S&CP

Document incorporates several

proposals prompted by the industry’s

experience in doing business using

OASIS. The How Group proposes

implementation six months after

approval by the Commission, in order to

allow four months for standards and

protocol development and beta testing

and two months for training and full

scale testing.

On August 29, 1997, we issued a

notice inviting public comment on the

August 12 submittal. Four comments
38886 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

13Comments on the How Group’s Phase IA

submittal were filed by AEP, How Group/

Commercial Practices Group, PECO, and Southern.

The How Group/Commercial Practices Group

comments included the September 23, 1997

revision of the Phase IA S&CP Document

incorporating clarifications and minor corrections.

In addition, on April 3, April 9, April 10, and

April 27, 1998, the How Group submitted a series

of corrections and revisions to its OASIS Phase IA

submittal incorporating various clarifications and

minor corrections to the S&CP Document. Each

successive submittal superseded all pending earlier

submittals. We issued a notice of the April 10, 1998

submittal and not of those earlier submittals that it

superseded (the April 27 corrections were

submitted as comments on the April 10, 1998

submittal). We expected to act on the latest

corrections of the How Group in this order.

However, with so many revisions, we are uncertain

that all errors have been identified. We therefore

invite the How Group to file with the Commission

a revised Phase IA submittal, within 21 days of the

date of issuance of this order, in WordPerfect 6.1

format, that to the greatest extent possible identifies

all needed corrections to the S&CP Document. We

request that the transmittal letter for this submittal

provide a complete explanation of all revisions and

why they are being proposed. We also request that

the submittal contain both a clean version and a

redline/strikeout version showing changes between

that version and the one being issued in this order.

We will issue a public notice when we these

documents are filed and will take action on the

How Group’s recommendations shortly thereafter.

14Source and sink information for point-to-point

transmission service describes the location of the

generators and the ultimate load in an electric

system sense, and does not necessarily identify

sellers and buyers by name. In accordance with the

convention of the transmission provider under its

individual Open Access Tariff (the Pro Forma Tariff

allowed each transmission provider to determine

this for itself in its Open Access Tariff filing) this

source and sink information may routinely include

only the identities of the respective control areas

(e.g., in the case of point-to-point transmission

across a transmission provider’s system, the point

of receipt is identified as a control area and the

point of delivery is similarly identified), or it may

include the identities of the respective bus bars of

the particular generators and loads (e.g., in the case

of transmission within, out of or into a transmission

provider’s transmission system). See, the Data

Element Dictionary, accompanying the S&CP

Document that, for template purposes, defines

‘‘source’’ as ‘‘[t]he area in which the SOURCE is

located’’ and ‘‘sink’’ as ‘‘[t]he area in which the

SINK is located.’’

The source and sink information here at issue is

the source and sink information reported on OASIS

templates. We are not addressing, and not requiring

the disclosure of, information collected from

customers as part of a complete application for

transmission service under the Pro Forma Tariff,

including information on whether the requested

transmission service is feasible (e.g., the NERC

‘‘tagging’’ information that might accompany the

scheduling of transmission service). See Coalition

Against Private Tariffs, and Western Resources,

Inc., 83 FERC ¶ 61,015 (1998), reh’g pending

(CAPT). CAPT is further discussed infra at notes 47,

74, and 76.

15See also ‘‘service request’’ transaction

templates at § 4.3.5 of the S&CP Document.

16Order No. 889–A, FERC Stats. & Regs. at

30,569–70.

17 Id. The How Group made this deletion in its

August 12, 1997, Phase IA filing.

18Order No. 889–B, 81 FERC at 62,175.

19 In its June 27, 1997 letter, the How Group

summarized the positions of interest groups as

follows:

• Transmission Providers generally do not have

a preference on this issue, although it is technically

easier for them if there is no masking on OASIS at

all.

• Transmission customers involved in merchant

activities strongly support having source and sink

identity masked from competitors indefinitely or for

as long as possible because they consider this

information to be business sensitive.

20The Commission invited comments on: (1) why

some parties consider this information to be

business sensitive or confidential while others do

not; (2) whether public access to this information

might harm competition and reduce efficiency, and

if so, why; (3) whether, in the event that source and

sink information continues to be masked,

competitors will be able to accurately infer this

information from other sources; and (4) the

implications of unmasking for contract path and

flow-based pricing regimes for reserving

transmission capability.

were filed and are referred to herein as

‘‘Comments on Phase IA’’.13

II. Discussion

A. Overview

In this order, we: (1) conclude that the

source and sink information reported on

OASIS transmission service request

templates should be unmasked at the

time when a transmission provider

updates the transmission reservation

posting to show the customer’s

confirmation that it wishes to finalize

the transaction; (2) require

modifications to the operative language

in the existing S&CP Document (Version

1.1) to incorporate our findings on

unmasking source and sink information

(to become effective on January 1, 1999)

and on proposed interim measures (to

become effective 60 days from the date

of publication of this order in the

Federal Register; and (3) adopt, with the

revisions discussed below, the Phase IA

S&CP Document (as corrected by the

How Group in its September 23, 1997

submittal), as Version 1.2, to become

effective on December 1, 1998. For

clarity, we address the issues raised by

the various How Group submittals and

related public comments on an issue-byissue basis.

B. Masking of Source and Sink Related

Information

The Commission has been asked to

decide whether certain information

routinely provided by potential

transmission customers, which pertains

to the location of the generator(s)

(source) and the location of the ultimate

load (sink) [collectively, source and sink

information] should be made publicly

available (by a posting on the OASIS) or

should be kept confidential (and made

available only to transmission system

operators). This information, which

helps define the transmission service

being requested,14 is submitted to the

transmission provider by the potential

transmission customer when it

completes the TRANSREQUEST

template as part of its initial request for

transmission service.

Under the current S&CP Document,

the source and sink information

becomes an element of the transmission

provider’s response to the potential

transmission customer’s query on the

status of its pending service request.15

However, since such information might

be used to infer the identifies of the

power supplier and the power

purchaser associated with a pending

transmission service request,

historically this element of the response

has been masked. In connection with

the masking of certain other

information, in Order No. 889–A, we

decided to delete the temporary

masking option provisions in our OASIS

regulations (formerly found in

§ 37.6(e)(1)(iii) and § 37.6(e)(3)(i), see

supra note 10) applicable to the

identities of the parties to the

transmission transaction (i.e., the

transmission provider and the potential

transmission customer), since our price

discount policy calls for the identities of

the parties negotiating the discount to

be made public during the negotiation

period.16 Accordingly, we asked the

How Group to eliminate any references

in the S&CP Document to the masking

of the identities of transaction parties.17

We reaffirmed this decision in Order

No. 889–B.18

In its June 27, 1997, submittal, the

How Group asks us to clarify whether

Order No. 889–A intended to require the

unmasking of the source and sink

information posted on the

TRANSSTATUS and other templates

covered by § 4.3.5b of the S&CP

Document. Although the How Group

prepared and provided a summary of

the positions of transmission providers

and transmission customers on this

issue,19 we invited further public

comments on the matter.20

Comments

1. Business Sensitivity and

Competitive Effect. It is not clear that all

commenters mean the same thing by

source and sink. Some appear to refer to

the exact location of the generation and

load, while others appear to refer to the

control area, which may cover a much

broader geographic area. With regard to

the impact that unmasking of source

and sink information may have on

competition, Commonwealth Edison,

CCEM, EPSA, and PECO Energy predict

that unmasking will result in the

elimination of the role that power

marketers play in electricity markets in

matching the needs of power suppliers
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38887

21EPSA Comments on How Group’s June 27 letter

at p. 4; PECO Energy Comments on How Group’s

June 27 letter at p. 4; Commonwealth Edison

Comments on How Group’s June 27 letter at p. 2;

and CCEM Comments on How Group’s June 27

letter at p. 7.

22Florida Power Corp Comments on How Group’s

June 27 letter at pp. 1–2.

23APPA Comments on How Group’s June 27

letter at p. 1.

24APPA Comments on How Group’s June 27

letter at p. 3.

25PJM Comments on How Group’s June 27 letter

at p. 1.

26NYSEG Comments on How Group’s June 27

letter at p. 2.

27Southern Comments on How Group’s June 27

letter at p. 4.

28EPSA Comments on How Group’s June 27 letter

at p. 4 and PECO Energy Comments on How

Group’s June 27 letter at p. 3.

29EPSA Comments on How Group’s June 27 letter

at p. 4 and PECO Energy Comments on How

Group’s June 27 letter at p. 4.

30EPSA Comments on How Group’s June 27 letter

at p. 4.

31CPEX Comments on How Group’s June 27 letter

at pp. 3–4.

32CCEM Comments on How Group’s June 27

letter at p. 4.

33NYSEG Comments on How Group’s June 27

letter at p. 1.

34NRECA Comments on How Group’s June 27

letter at pp. 1–2.

35Commonwealth Edison Comments on How

Group’s June 27 letter at p. 2.

36Commonwealth Edison Comments on How

Group’s June 27 letter at p. 3 and Florida Power

Corp Comments on How Group’s June 27 letter at

p. 3.

37NRECA Comments on How Group’s June 27

letter at pp. 1–2.

38PECO Energy Comments on How Group’s June

27 letter at p. 2 and Commonwealth Edison

Comments on How Group’s June 27 letter at p. 4.

39CPEX Comments on How Group’s June 27 letter

at pp. 1–3.

to sell their generation output with the

needs of power purchasers to meet their

loads.21 They posit that once the

location of the generating facility

(source) and the location of the load

ultimately served (sink) for each pointto-point transmission service

transaction is made publicly available,

such information will be used by each

party (i.e., the power supplier and the

power purchaser) to match up their

respective needs and deal directly with

each other, if possible, to their mutual

advantage and to avoid the power

marketer’s mark-up.

Florida Power Corp believes that

unmasking source and sink information

will eliminate some opportunities for

marketers, if this information is made

publicly available when transmission

services are reserved, because power

suppliers and power purchasers will

then have time to negotiate directly.22

APPA points to the technical burden

that masking efforts place on

transmission providers.23 It further

argues that the bypass of power

marketers that might be caused by

unmasking is actually an efficient

outcome, if all that unmasking adds to

the overall transaction is the possibility

of direct matching of the power supplier

and the power purchaser. APPA asserts

that those entities warning that the

unmasking of source and sink

information will cause harm to power

marketers are really confusing a threat

of private harm with societal harm. In

its view, making source and sink

information publicly available would

serve the interests of ultimate

customers.24

PJM sees no reason to mask source

and sink information. It believes that

providing this information to all market

participants will increase both

competition and the overall efficiency of

the market.25 NYSEG shares the view

that electricity markets may become

more efficient with more transmission

information made available on a nondiscriminatory basis.26

Southern suggests that the

Commission should not unmask source

and sink information unless it has a

strong policy reason to do so.27 Both

EPSA and PECO Energy acknowledge

the apparent benefit of unmasking

source and sink information, but

contend that such benefits will not be

realized in practice, especially at this

early stage when competitive electricity

markets are still evolving.28 They also

argue that unmasking source and sink

information would result in the loss of

significant benefits they claim power

marketers now bring to electricity

markets, including liquidity, risk

management, and creativity in meeting

the unique needs of power suppliers

and power purchasers.29 EPSA foresees

the competitiveness of electricity

markets being undermined by

unmasking, with markets eventually

returning to monopoly power suppliers

and captive power purchasers.30 CPEX

also sees unmasking as a serious threat

to competitive electricity markets.31

CCEM makes the commercial business

argument that unmasking will compel

power marketers to give up the benefits

that they provide without being

compensated.32 It further argues that the

threat of after-the-fact audits should be

sufficient to discourage instances of

undue discrimination in the provision

of transmission services and that

unmasking is unnecessary for this

purpose.

With regard to more improved

utilization of transmission systems,

NYSEG asserts that unmasking will

allow all transmission users to gauge

what impact a given transmission

service transaction will have on the

transmission provider’s system.33

NRECA suggests unmasking will

provide transmission users with a better

idea of the planned and scheduled uses

of the transmission system and what

additional transmission capacity is

available. While it supports making

source and sink information available at

the time when transmission providers

and potential transmission customers

finalize reservations and energy

schedules, NRECA opposes unmasking

during the period when transmission

reservation requests and the associated

off-OASIS energy schedule requests are

still pending.34 Commonwealth Edison

sees any enhancement of transmission

system capacity analysis by

transmission customers resulting from

the disclosure of source and sink

information, as being only theoretical. It

asserts that postings of ‘‘available

transmission capacity’’ (ATC) provide

sufficient information for customers to

analyze the impacts that various

transmission transactions may have on

the transmission system and its users.35

2. Other Information Sources and the

Need for Source and Sink Information.

With regard to whether similar

information might be available

elsewhere, which would allow the

identity of the power supplier and the

power purchaser associated with a given

transmission transaction to be inferred

even if masking is continued,

Commonwealth Edison and Florida

Power Corp opine that it would be

extremely difficult to bypass power

marketers by obtaining similar

information from other sources.36

NRECA contends that source and sink

information will be available from the

NERC transaction information system or

the tagging form.37 PECO Energy and

Commonwealth Edison believe that

unmasking should not be viewed as a

reliability matter.38

Some commenters question the

underlying need for source and sink

information, even if it is not made

publicly available. CPEX asserts that

requiring source and sink information is

an unnecessary burden on merchants

and that the only information that

system operators need to assure

transmission reliability is information

on power being sent and received

through their control areas.39 In CPEX’s

view, this is sufficiently covered by

ATC without need for specific

information on the source and the sink.

CPEX further claims that transmission

curtailment is only infrequently needed

and, when it is, it is implemented by

shifting among alternative generation

sources without reliance on source and

sink information. APPA, however,
38888 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

40APPA Comments on How Group’s June 27

letter at p. 4.

41EPSA Comments on How Group’s June 27 letter

at pp. 5–6.

42Flow-based pricing, unlike contract path

pricing, may recognize all of the paths that a given

transmission transaction utilizes. See Order No.

888, FERC Stats. & Regs. at 31,650 n.95.

‘‘[I]n contrast to contract path pricing, flow-based

pricing establishes a price based on the costs of the

various parallel paths actually used when the

power flows. Because flow-based pricing can

account for all parallel paths used by the

transaction, all transmission owners with facilities

on any of the parallel paths could be compensated

for the transaction.’’

43PJM Comments on How Group’s June 27 letter

at pp. 1–2.

44Florida Power Corp Comments on How Group’s

June 27 letter at pp. 3–4.

45APPA Comments on How Group’s June 27

letter at p. 5.

46The Commission, elsewhere, has previously

addressed NERC’s tagging requirements. See, CAPT

supra note 15. 

47We earlier defined the source and sink

information here at issue, supra notes 9 and 14.

48Our decision to require that certain potentially

sensitive business information be disclosed is

consistent with judicial directives to focus on the

needs of the overall market, instead of on

individual competitors within the market. In

Alabama Power Company v. Federal Power

Commission, 511 F.2d 383, 390–391, D.C. Cir.

(1974), we had refused to amend our rule that

required affected utilities to publicly disclose their

monthly Form No. 423 reports of fuel purchases.

The court considered various arguments to the

effect that, on the one hand, ‘‘disclosure of

information would lead to bargaining disadvantages

in future fuel contract negotiations’’ (511 F.2d at

390), and on the other hand, any bargaining

disadvantage as a result of disclosure would merely

reflect the removal of information imperfections in

an otherwise competitive market thereby facilitating

efficient allocation of resources. [Id.]

Notably, the court found that,

‘‘a sudden improvement in the availability of

information may deprive a buyer of an advantage

he enjoyed when, under more imperfect

dissemination, he exploited a seller’s ignorance of

the market price. * * * Generally, however, laws

and practices to safeguard competition assume that

its prime benefits do not depend on secrecy of

agreements reached in the market. [Id. at 391,

n.13.]’’

49We are revising the operative statement in

§ 4.3.7.2 of the S&CP Document (Version 1.1) that

reads ‘‘[o]ther fields, such as SOURCE and SINK,

may be masked to comply with FERC regulations

and Primary Provider tariff’’ to read as follows:

‘‘Transmission Providers shall make source and

sink information available at the time the request

status posting is updated to show that a

transmission request is confirmed.’’

complains that NERC has a policy of

treating tagging information as

confidential.40 Finally, EPSA contends

that the adverse competitive impacts of

unmasking outweigh the limited

benefits of source and sink information

being collected, since the information is

of only marginal relevance in the rare

situation when there is a transmission

constraint.41

3. Differing Impacts on Contract Path

and Flow-Based Transmission Pricing

Regimes. With regard to whether

unmasking source and sink information

affects either a contract path or flowbased transmission capacity pricing

regime,42 PJM sees unmasking making

no difference.43 Florida Power Corp

notes that the method of calculating

ATC for transmission service

reservation purposes for either pricing

regime is the same and, for this reason,

asserts that neither pricing regime

influences the decision of whether this

information should be unmasked.44

Finally, APPA asserts that source and

sink information is essential under both

transmission reservation pricing regimes

for determining the potential impact of

a request and all parties should have

equal and full knowledge of this

information.45

Commission Conclusion

Initially, we note that this proceeding

does not concern whether the

transmission provider should collect

source and sink information from a

potential customer seeking point-topoint transmission service. Point of

receipt and point of delivery

information is necessary for the

transmission provider and we are not

entertaining comments directed at

challenging the necessity to collect this

type of information in this proceeding.

Nor does this proceeding concern

questions regarding NERC tagging

information.46

The issue here is whether to unmask,

that is, make known to all parties, pointto-point transmission service source and

sink information now made known to

transmission system operators. We are

persuaded that such source and sink

information 47 should be disclosed

publicly through an OASIS posting at

the time when the transmission

provider updates the OASIS posting to

show that a customer has confirmed its

request for point-to-point transmission

service. As we explain below, we

believe that disclosure of this

information will foster greater public

confidence in the integrity of OASIS

systems and improve the ability of such

systems to facilitate open access use of

transmission systems comparable to that

enjoyed by the transmission providers.

We also believe that unmasking can be

accomplished without compromising

the role that power marketers play in

electricity markets.

First, the disclosure of source and

sink information will provide wholesale

transmission customers and others with

useful data for the after-the-fact

evaluation of the accuracy of

transmission providers’ OASIS postings

of ATC and total transmission capacity

(TTC). Second, disclosure will also

provide useful information for

discerning any patterns of undue

discrimination in the rendering of or

refusals to provide transmission services

and in price discounting by

transmission providers. Thus,

disclosure should encourage accurate

postings and fair treatment leading to

better competitive utilization of

transmission systems.

While we acknowledge the potential

business sensitivity that power

marketers attach to source and sink

information, we believe that delaying

unmasking until the transmission

provider updates the transmission

reservation posting to show the

customer’s confirmation should allow

the power marketer to finalize its

arrangements with the power purchaser

and the power seller. Moreover,

delaying disclosure will not result in the

public at large losing the benefits that

disclosure offers to all transmission

users, including power marketers, since

assessments of the accuracy of posted

information and unduly discriminatory

activity based on such information will

of necessity be conducted on an afterthe-fact basis. We caution that our

overriding concerns are with the

promotion of the overall

competitiveness of the electricity

markets and with ensuring openness,

confidence, and nondiscrimination in

the use of interstate transmission

facilities.48

We thus require that transmission

providers unmask the source and sink

information that is posted on

TRANSSTATUS and other templates at

the time when a request status posting

is updated by the transmission provider

to show that the customer has

confirmed, in response to the

transmission provider’s acceptance of

its offer, that it still wants to complete

the transaction and purchase

transmission service. Accordingly, we

order corresponding revisions to be

made to the masking requirements of

the S&CP Document.49 However, in

recognition of the concerns expressed in

this proceeding regarding the potential

business sensitivity of source and sink

information and the somewhat limited

experience the Commission has had

with the OASIS, we determine it is

appropriate to delay the implementation

of these revisions for seven months.

This will permit competitive electric

markets additional time to develop.

Therefore, these revisions are to become

effective on January 1, 1999.

Our decision to unmask source and

sink information is consistent with
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38889

50Section 17.2(iv) of the Pro Forma Tariff (Stats.

& Regs., Regulations Preambles at 30,522) reads:

‘‘The location of the generating facility(ies)

supplying the capacity and energy and the location

of the load ultimately served by the capacity and

energy transmitted. The Transmission Provider will

treat this information as confidential except to the

extent that disclosure of this information is required

by this Tariff, by regulatory or judicial order, for

reliability purposes pursuant to Good Utility

Practice or pursuant to RTG transmission

information sharing requirements. The

Transmission Provider shall treat this information

consistent with the standards of conduct contained

in Part 37 of the Commission’s regulations.

Section 18.2(vii) of the Pro Forma Tariff (Stats. &

Regs., Regulations Preambles at 30,524) reads in

relevant part:

‘‘The Transmission Provider will treat this

information in (vi) and (vii) as confidential at the

request of the Transmission Customer except to the

extent that disclosure of this information is required

by this Tariff, by regulatory or judicial order, for

reliability purposes pursuant to Good Utility

Practice, or pursuant to RTG transmission

information sharing agreements. The Transmission

Provider shall treat this information consistent with

the standards of conduct contained in Part 37 of the

Commission’s regulations.’’

51We noted in Order No. 889–A, FERC Stats. &

Regs. at 30,551 and n.12, that ‘‘negotiation’’ would

be considered to have taken place only if the

transmission provider or transmission customer

seeks prices below the ceiling prices set forth in the

Order No. 888 Pro Forma Tariff.

52CCEM Comments on Interim Measures at pp.

11–12.

53CCEM Comments on Interim Measures at p. 11.

54 Id.

55Commonwealth Edison Comments on Interim

Measures at pp. 4–5.

56Southern Comments on Interim Measures at p.

2.

57Florida Power Corp Comments on Interim

Measures at pp. 4–5.

sections 17.2 and 18.2 of the Pro Forma

Tariff.50 These sections provide that a

transmission provider, unless otherwise

ordered to do so, is obligated to treat

confidentially information that is

supplied as part of a Completed

Application for transmission service

pertaining to the location of the

generator and the location of load

ultimately served. We herein find that

the obligation in the Pro Forma Tariff to

treat such information confidentially

does not contradict the requirement we

are establishing in this order to unmask

the source and sink information

reported on the TRANSSTATUS and

other S&CP Document templates at the

time when the transmission provider

posts on the OASIS that the customer

confirms that it wants to complete the

transaction. As noted above, supra note

50, the Pro Forma Tariff provides that

transmission providers are to keep

certain information on source and sink

confidential at the request of a

transmission customer, except in

specified circumstances, which include

a regulatory order requiring disclosure.

In this regulatory order, we make just

such an exception. Accordingly, the

requirement in this order to disclose

certain source and sink information is

consistent with the requirements of the

Pro Forma Tariff.

C. Proposed Interim Procedures To

Achieve On-line Price Negotiation and

Disclosure of Discounts in Phase I

OASIS Until Phase IA Changes Are

Implemented

The How Group’s proposed interim

procedures contain two separate

components. Under the first,

transmission service negotiations would

be accomplished by allowing a potential

transmission customer to make a bid by

modifying the offered transmission

price in the price field of the

TRANSREQUEST template.51 The

transmission provider would then

respond to the bid price by using the

TRANSSTATUS template to notify the

potential customer of whether the bid

was accepted or rejected. This

modification of the price field would

require only a minor change to most

OASIS nodes.

The second proposed interim

procedure would create a new category

(‘‘discounts’’) in the MESSAGE template

to announce agreed-upon transmission

service price discounts. A price

discount for a non-standard

transmission related service, such as

weekly service beginning on a

Wednesday at 2:00 p.m., would be

reported only in the MESSAGE

template.

The How Group requested that the

industry be given two months to test

these interim modifications to OASIS

templates and implement the interim

measures. While maintaining that its

interim procedures are a somewhat

cumbersome method to implement online transmission service negotiations,

the How Group contends that the

interim measures will allow

negotiations to proceed on the OASIS

while a more satisfactory method is

developed.

Comments

CCEM contends that on-line

negotiation of transmission prices is not

feasible at this time because the

Internet-based OASIS cannot currently

accommodate the speed at which

negotiation should comfortably take

place. It argues that the interim on-line

negotiation process will be so

cumbersome that transmission

providers will lose interest in price

discounting.52 CCEM also sees the

disclosure of transmission price

discounts raising business sensitivity

concerns and suggests that real time

discount price disclosure is not the only

means available to prevent unduly

discriminatory treatment of

transmission customers. As an

alternative, CCEM suggests that

transmission service negotiations

proceed off-OASIS through a process

that would rely on phone or facsimile

communication arrangements between

transmission providers and potential

transmission customers.53 Under

CCEM’s proposal, whenever a

transmission price discount is agreed

upon, the availability of the price

discount would be broadcast and

disseminated on-line over OASIS

(within 12 hours in the case of an

affiliated customer and within 15 days

in the case of a non-affiliated

customer).54

Commonwealth Edison argues that

transmission service negotiations offOASIS should continue, based on

concerns about whether price

negotiations could be conducted

successfully through present OASIS

nodes under the interim measures,

given the many steps, the amount of

time involved, and the OASIS capacity

needed to handle the increased volume

of the related communications.55

While supporting electronic

negotiation of transmission prices, and

noting that the NYPP OASIS node could

implement the interim measures now,

NYSEG also prefers to wait until a realtime or faster Internet-based OASIS

system is developed. NYSEG suggests

that, during the interim, transmission

negotiations rely on recorded telephone

calls with any agreed-upon price

discounts posted on the OASIS within

thirty minutes of the completion of the

negotiations.

PJM notes that no changes will be

required to the PJM OASIS to

implement the How Group’s interim

measures. Southern, however, cautions

that OASIS systems are still in the early

stages of development and that

requiring the capability for on-line

negotiation of transmission price

discounts, at this critical stage, would

add further complexity to the design of

OASIS nodes that could slow down the

transmission reservation process and

actually could impede the growth of

more robust power trading.56

Florida Power Corp agrees that the

proposed interim measures could be

implemented through modification of

existing OASIS templates, but stresses

that price negotiations will be very

cumbersome and not practical,

especially for short-term transactions. It

suggests that negotiations be conducted

by telephone calls, with the results

immediately posted on OASIS.57
38890 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

58NRECA Comments on Interim Measures at p. 3.

Although NRECA argues that ‘‘timely’’ responses

are needed, it seeks no revisions to the timetables

for posting in 18 CFR 37.6. This issue is also raised

by PECO in their comments to Phase IA.

59PECO Energy Comments on Interim Measures

at p. 7.

60Order No. 889–A, FERC Stats. & Regs. at 30,551.

61We note, however, that in section II.G infra, we

accept the How Group’s proposal to add a

negotiation flag in the TRANSSTATUS template to

enable customers to search for discounts, as part of

the Phase IA S&CP Document revisions.

62This modification is more fully explained in

note 63, infra.

63 In the interim, until the revised S&CP

Document Version 1.2 (see Attachment 2) becomes

effective, we will modify the operative language of

S&CP Document Version 1.1, as proposed in the

How Group’s June 27, 1997 letter with some minor

clarifications, through the addition of the following

language to § 4.3.7:

‘‘For on-line price negotiation the customer can

modify the price field when submitting a request to

purchase transmission service using the

TRANSREQUEST template. The provider response

in the TRANSSTATUS template will either indicate

‘‘accepted’’ if the bid is approved, or ‘‘denied’’ if

the bid is not accepted. The reason for denial would

be shown in the comments field. The

TRANSSTATUS template would retain the

customer’s bid price as a permanent record,

whether accepted or not. If the request is denied for

price reasons, the customer could repeat the process

by submitting a new request with a different price

bid. If a discount is given on a posted product, it

is also required that the transmission provider

change the posted offer price to match the

discounted price for the service, for all

unconstrained paths to the same point of delivery

(POD) and for the same time period.’’

This insertion would precede ‘‘a. Customer

Capacity Purchase Request’’ in § 4.3.7 of the S&CP

Document. We are making this change through the

issuance of this order and not through the issuance

of an updated S&CP Document because it is to be

in effect for only a limited time.

64Changes directed by the Commission include:

(1) provision for on-line interactive negotiation

(such as the addition of new data elements for price

offered, price bid, ceiling price); (2) provision for

linking ancillary services to transmission services;

(3) provision for identification of a reservation

made by an affiliated merchant; (4) provision for

posting personnel transfers; (5) provision for

posting incidents in which the provider exercises

discretion in the application of tariffs; and (6)

removal of all references in the S&CP Document to

masking.

Improvements suggested by industry’s experience

include: (1) automatic notification of customers

(dynamic notification) when the status of a

reservation request has changed (to speed up the

process of negotiating by reducing the customer’s

need to check an OASIS node repeatedly for the

status of a pending request); (2) merging all

transmission service offering templates into a single

template (to simplify doing business); (3) further

standardization of transmission service product

names and identification of their attributes; (4)

introduction of ‘‘sliding windows of time’’ allowing

purchases of blocks of service (running 60 minutes,

24 hours, 7 days, or 30 days) on a non-calendar

period basis; (5) introduction of ‘‘capacity profiles’’

reservations (allowing for a single reservation for

monthly service to set different levels of reserved

capacity for each day thereof); and (6) a new

template for nonfirm secondary service over

alternate points of receipt and delivery (provides

additional support for secondary transmission

service).

65 In Attachment 3 to this order, we show all the

changes that we have made and direct to the How

Group’s September 23, 1997, submittal in redline

and strikeout fonts. In Attachment 2, we provide

the revised document without redline and strikeout

fonts. Attachments 2 and 3 will be posted on the

Commission Issuance Posting System (CIPS) and

may be reviewed in the Commission’s Public

Reference Room during normal business hours.

Details about accessing CIPS are given in the

supplementary information preceding this order,

supra at ii.

NRECA asserts that the interim

measures will work effectively only if

transmission providers respond in a

timely manner to transmission customer

requests for price discounts. However, it

is willing to accept the interim measures

even though they constitute a retrofit

and would have developed differently if

considered in the initial OASIS design

stage.58

PECO Energy argues that transmission

negotiations off-OASIS should continue,

since the majority of transmission

providers may not be able to

successfully implement the software

changes necessary for on-line

negotiation of transmission prices over

OASIS. PECO opposes mandatory

interim measures for on-line negotiation

until OASIS is greatly improved.59

However, it believes that price

discounts should be disclosed when

offered to affiliates and non-affiliates

alike, following the completion of the

negotiations.

Commission Conclusion

As we stated in Order No. 889–A,60

the objective of the interim procedures

is to implement our Order No. 888–A

on-line transmission price negotiation

policy as soon as possible through

OASIS, so we can improve the

competitiveness of the electricity

markets while the industry develops a

more sophisticated ‘‘Phase IA’’

approach. Keeping this in mind, we are

adopting the first of the How Group’s

two proposed interim measures

(involving modifications to the price

field of the TRANSREQUEST template)

because it appears that this interim

modification can be easily made. We are

not adopting the How Group’s second

proposal (involving a new ‘‘discounts’’

flag in the MESSAGE template) because

this revision is more complex and we

wish to keep the burden of

implementing the interim procedures to

a minimum.61 Under this limited

interim procedure, wherein we merely

allow the price field to be modified,62 a

potential transmission service customer

will be able to request discounts via

OASIS, but only on posted transmission

service offerings. No commenter has

provided persuasive evidence that the

How Group’s proposal cannot be

implemented within the How Group’s

proposed time frame.

Relying on the How Group’s interim

proposal, we direct changes to the

operative language of the current S&CP

Document to allow a potential

transmission customer to modify the

price field when submitting a request to

purchase transmission service using the

TRANSREQUEST template.63 If the

customer’s bid is approved, the provider

will respond by posting the message

‘‘accepted’’ in the TRANSSTATUS

template. If the customer’s bid is not

accepted, then the provider will

respond by posting the message

‘‘denied.’’

We require implementation of this

directive by September 11, 1998 so that

discounts can be requested on-line

without waiting for the industry to

implement comprehensive changes in

Phase IA OASIS.

We believe the benefits of fostering

on-line discounting as soon as possible

in this limited fashion outweigh the

problems that may result from the use

of a somewhat cumbersome process and

find this preferable to waiting until

OASIS Phase IA improvements can be

implemented before implementing online discounting. As to any business

sensitivity concerns over our decision to

make price negotiation visible on

OASIS, the time to raise these concerns

was in the rehearing of Order No. 889–

A and not at this compliance stage.

D. How Group Proposals To Revise the

Phase IA S&CP Document Requirements

The How Group’s proposed longer

term revisions incorporated in a Phase

IA S&CP Document (Version 1.2)

include both the changes we directed in

Order No. 889–A and other changes

prompted by the industry’s experience

with operating OASIS sites.64 Except as

discussed below, we find these

modifications to the S&CP Document to

be acceptable and direct its revision

with minor editorial changes to correct

typographic errors, enumeration of

sections, and other nonsubstantive

changes.65 Additionally, interested

persons filed comments on certain of

the proposed revisions to the S&CP

Document, which we also address

below.

1. Comments on Preconfirmed

Reservations

In connection with transmission

service negotiations, Section 4.2.10.1(a)

of the How Group’s proposed Phase IA

S&CP Document indicates that OASIS

shall set OFFERlPRICE equal to

BIDlPRICE in the case of
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38891

66AEP Comments on Phase IA at p. 5.

67See Order No. 889–A, FERC Stats. & Regs. at

30,568.

68AEP Comments on Phase IA at pp. 5–7.

69Southern Comments on Phase IA at pp. 4–5.

70Southern Comments on Phase IA at pp. 5–6.

71AEP Comments on Phase IA at pp. 7–8.

‘‘preconfirmed’’ transmission

reservation requests. AEP states that this

proposal should satisfy the restriction/

requirement that BIDlPRICE be equal

to OFFERlPRICE for any reservation to

be CONFIRMED; 66 however, AEP is

concerned that parties to a preconfirmed

transaction using the proposal may

inappropriately modify or unwittingly

accept price information. Thus, it

requests that we substitute the following

requirement:

Prior to or commensurate with a Seller’s

setting a preconfirmed reservation request’s

STATUS to ACCEPTED (and by implication

CONFIRMED), the Seller must set

OFFERlPRICE equal to the value of the

BIDlPRICE as established by the Customer

on submission of the request.

Commission Conclusion

The Commission adopts AEP’s

suggestion and proposed wording for

the Phase IA S&CP Document. It is more

specific and thus less subject to

differing interpretations. AEP’s proposal

clarifies that the setting of the

OFFERlPRICE equal to the

BIDlPRICE occurs only when the

Seller accepts the preconfirmed request.

We remind transmission providers that

our OASIS regulations require that, if

discounts are offered, they be offered to

all transmission customers.67

2. Comments on Linking Ancillary and

Transmission Services

The How Group proposes adding

§ 4.2.12 to conform the S&CP Document

to the revisions directed by Order No.

889-A in connection with §§ 37.6(c)(4)

and 37.6(e)(1)(iv) of the Commission’s

OASIS regulations, which require that

transmission service offerings and

transaction status postings identify the

associated ancillary services and

ancillary service transaction status.

AEP notes that the Commercial

Practices Group white paper

recommendation on the handling of

ancillary services during Phase IA, i.e.,

that

basic point-to-point transmission service

should be requested before any Ancillary

Services to support that basic point-to-point

transmission service are requested

was not incorporated in the How

Group’s proposal. AEP requests

that the Commission adopt a provision that,

for OASIS Phase IA, all ancillary service

transactions/reservations are subordinate to

and in support of a single transmission

service reservation.

AEP argues that adoption of this

provision would significantly simplify

the implementation of the How Group’s

proposal. AEP contends that, if one

considers pre-arrangement for Operating

Reserve-Spinning Reserve from a third

party ancillary service provider, that

service provider will require

notification that some or all of that

service is supporting one or more

transmission reservations made at some

point in the future as those reservations

are confirmed. As currently there is no

proposed mechanism to query OASIS

for reservations that reference this prearranged ancillary service reservation,

AEP questions whether the third-party

supplier market for ancillary services is

robust enough to warrant the significant

investment in programming resources

needed to implement the How Group’s

proposal without such modification.68

Southern contends that the How

Group’s proposal to allow transmission

customers to indicate a preferred

provider of ancillary services and

indicate which services will be

purchased in the future, injects

confusion into the reservation process

by giving transmission customers

options inconsistent with the Pro Forma

Tariff. It also asserts that the proposal is

unnecessary because the existing

‘‘request reference’’ or ‘‘deal reference’’

fields can be used to link ancillary and

transmission services as required by the

Commission.69

Commission Conclusion

We believe that AEP’s suggestion to

limit the flexibility inherent in the

ancillary services linkage proposal

reduces the Phase IA programming

necessary to implement the proposal

and is a practical suggestion.

Nonetheless, while we adopt its

suggestion that requests for ancillary

service be associated with a single

transmission service reservation, we

find it unnecessary to completely adopt

AEP’s recommendation for the

Commission to require that basic pointto-point transmission service must be

requested before any request is made for

supporting ancillary services. This

would interfere with customers

attempting to take advantage of certain

optional ancillary service packages

transmission providers offer with their

transmission service offerings.

Therefore, ancillary services may be

requested before, concurrently with, or

subsequent to, the related request for

basic point-to-point transmission

service.

We also agree with Southern that it is

the Pro Forma Tariff, and not the OASIS

regulations, that controls the minimum

ancillary services that must be offered

by a transmission provider. However,

the How Group’s Phase IA proposal

merely attempts to accommodate the

reservation options that transmission

customers may have under a particular

transmission provider’s Pro Forma

Tariff. To the extent that Southern has

a feasible but simpler approach to

handle ancillary service linkage, we

encourage it to pursue its idea with the

How Group to improve § 4.2.12 of the

S&CP Document.

3. Comments on Capacity Profiles

The How Group proposes to

introduce, in Phase IA, the concept of

capacity profiles for reservations of

varying amounts of capacity over a

given service period. For example, a

single OASIS transaction would cover a

weekly reservation that incorporates

varying daily reservation levels.

Southern asks for rejection of the

capacity profile mechanism, claiming

that OASIS, as it is currently configured,

permits transmission customers to

accomplish the same result through the

submissions of multiple requests, each

tied to the others through a common

deal reference number supplied by the

transmission customer and that, in any

event, the computer systems of

transmission providers are not set up for

this process. Southern implies that the

capacity profile reservation mechanism

is also not feasible because the Pro

Forma Tariff does not include

provisions that allow transmission

customers to make reservations based

on capacity profiles.70

AEP questions whether transmission

customers should be able to negotiate

the price of the individual hours of a

capacity profile. It claims that the S&CP

Document has also defined the

templates used to negotiate the

transmission price of the individual

hours of a capacity profile in an

inconsistent and ambiguous manner.

AEP, therefore, requests that any

reference to pricing information for the

individual hours of capacity profiles be

removed.71

Commission Conclusion

The How Group’s Phase IA proposal

for implementing capacity profiles in

§ 4.3.7.1 of the S&CP Document leaves

the adoption of the capacity profile

transaction process to the option of each

transmission provider:

[s]upporting ‘‘profiles’’ of service, which

request different capacities for different time
38892 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

72August 12, 1997 How Group Letter at p. 48.

73PECO Comments on Phase IA at p. 2.

74While these data elements would inform

customers of the curtailment priorities of NERC and

various regional entities, curtailment priorities for

transmission providers that are public utilities are

governed by the applicable Pro Forma Tariff unless

the Commission approves a transmission provider’s

proposal to revise its Pro Forma Tariff based on a

showing that its revised curtailment priorities are

consistent with or superior to the Pro Forma Tariff.

See CAPT, supra note 14. Absent such an approved

tariff revision, to the extent that a conflict exists

between the curtailment priorities of NERC or

another entity and the applicable Pro Forma Tariff,

the Pro Forma Tariff shall govern.

75How Group/Commercial Practices Group

Comments on Phase IA at pp. 1–2.

76As we advised in CAPT supra note 14:

[t]he Commission further encourages the industry

to examine reliability aspects of the Pro Forma

Tariff when additional detail may be required to

implement specific reservation, scheduling, and

curtailment procedures and to propose generic

improvements to the Pro Forma Tariff.

Such proposed detail cannot be considered

approved by the Commission by virtue of our

approving its display on the OASIS.

77AEP Comments on Phase IA at p. 2.

78AEP Comments on Phase IA at pp. 2–3.

periods within a single request, are at the

discretion of the Primary Provider.72

Accordingly, AEP, Southern, and other

transmission providers will be free to

decide whether to implement the

capacity reservation profiles on their

individual OASIS nodes within the

parameters of the service offering

prescribed by their respective Pro Forma

Tariffs. The revisions to the S&CP

Document which we adopt today merely

provide a consistent method to follow

by transmission providers in the event

they choose to offer capacity reservation

profiles.

4. Comments on Posting of Losses

PECO points out that, while

transmission customers must account

for losses when making a transmission

reservation, it can be a very time

consuming process for customers to

search through the transmission

provider’s tariff to determine how losses

will be applied on systems where losses

vary from path to path.73 PECO proposes

either that the transmission provider’s

response to a request for transmission

service via the ‘‘TRANSOFFERING’’

template include loss information or,

alternatively, that a table of losses be

posted on the OASIS by the

transmission provider.

Commission Conclusion

PECO raises a valid concern. While

we encourage transmission providers to

post a table of losses on their OASIS

nodes because such information is

useful to transmission customers, we

will not require it at this time because

we believe that transmission users

would be best served if loss information

were provided in a standardized

template. Therefore, we request that the

How Group consider this as part of the

OASIS Phase II process.

5. Revisions to Phase IA S&CP

Document Recommended by the How

Group and the Commercial Practices

Group

In their joint comments, the How

Group/Commercial Practices Group

recommend one change, and several

clarifications and minor corrections to

the proposed Phase IA S&CP Document.

The change pertains to the addition of

two data elements requiring the

establishment of two new fields

(NERClCURTAILMENTlPRIORITY

and

OTHERlCURTAILMENTlPRIORITY)

to several templates (TRANSOFFER,

TRANSSTATUS, LIST, TRANSSERV,

SCHEDULE, CURTAIL, TRANSSELL,

TRANSPOST), to inform transmission

customers about the NERC curtailment

priority and other regional curtailment

priority assigned to each transmission

service offering.74 These priorities are

set by the transmission provider,

consistent with the tariff on file with the

Commission. The minor changes

include enumeration, typographical,

sequencing, identification, and format

corrections and fixes.75

Commission Conclusion

We adopt the new data elements as an

option that transmission providers may

display because they provide useful

information. However, we caution that

our adoption of a place on the OASIS

for these data elements does not

constitute an approval of the NERC or

other curtailment priorities.76 We also

adopt the proposed corrective

suggestions for Phase IA purposes

because they improve and help

complete the S&CP Document.

E. Other Proposed Revisions to the

S&CP Document

1. Comments on Standardized Naming

of Transmission Paths

AEP raises the issue of the need for

consistent naming of point-to-point

transmission paths among transmission

providers’ systems. It observes that

inconsistent naming of paths among

transmission providers has had a

significantly negative impact on

transmission customers’ ability to

effectively use OASIS to procure needed

transmission services. AEP, therefore,

proposes its own naming convention for

transmission paths:

Where a point of receipt and/or delivery

(data elements POINTlOFlRECEIPT and

POINTlOFlDELIVERY) represents a NERC

Control Area, the NERC 4 character Control

Area acronym shall be used as the name of

that point of receipt and/or delivery.

Where a path (dat[a] element

PATHlNAME) represents the

interconnection between two NERC Control

Areas, the PATHlNAME shall be composed

of: ‘‘REGIONlCODE/

PRIMARYlPROVIDERlCODE/

PATHlCODE//’’. REGIONlCODE and

PRIMARYlPROVIDERlCODE are as

defined in the Data Element Dictionary.

PATH—CODE shall be composed of the

POINTlOFlRECEIPT followed by the

hyphen (-) character and

POINTlOFlDELIVERY, where

POINTlOFlRECEIPT and

POINTlOFlDELIVERY are the associated

NERC 4 character Control Area acronyms.

OPTIONALlCODE and SPARElCODE are

null.77

Commission Conclusion

We agree with AEP that a consistent

naming convention of paths will greatly

improve the usefulness of Phase IA

OASIS. However, in this instance, we

are reluctant to impose a change in a

business practice without giving the

industry the opportunity to consider

other possibilities and reach a

consensus on the best solution. Since

the Commercial Practices Group has

been formed to develop business

practice standards for OASIS, we

request that the Commercial Practices

Group propose a consistent naming

convention for transmission paths by

August 31, 1998.

2. Comments on Reservation Templates

AEP notes that the cumbersome

process that transmission customers

must follow in making arrangements for

transmission service on OASIS is made

more cumbersome by those

transmission providers that require

submission of reservation requests to

enter and exit their systems for

‘‘passthrough’’ or ‘‘wheeling’’ type

transactions.78 AEP suggests that a

single reservation request should be

sufficient to cover both entering and

existing the transmission system for

such service. AEP asks that we modify

the S&CP Document (or the OASIS

regulations) to the extent necessary to

enable transmission customers to rely

on a single reservation transaction for

wheeling across a transmission system

regardless of whether the particular path

is posted.

Commission Conclusion

AEP is correct that our rules currently

do not require postings in a manner that

a allow a single reservation transaction

for wheeling across a transmission

system, without a specific advance
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38893

79 18 CFR 37.6(b)(1)(i).

80Such an approach requires foresight by the

customer (or by the transmission provider). If the

customer has not made a request in advance that

the path at issue be posted, then it would not be

posted in time to accommodate the transaction

(unless posted at the request of another customer).

81See supra note 64.

82How Group’s August 12, 1997, letter at

Attachment 1.

83Order No. 889, FERC Stats. & Regs. at 31,621–

22, requires transmission providers to post resales

of capacity from their transmission systems, on

their OASIS nodes. To prevent transmission

providers from gaining a competitive advantage

over resellers, transmission providers must post

such information on the same display page using

the same tables used for their own offerings.

Transmission providers must also provide postings

of offers to sell ancillary services on the same page

and in the same format that they use for their own

offerings.

84AEP Comments on Phase IA at pp. 3–4.

Specifically, AEP proposes:

‘‘As an extension of the Company registration

information of the host, domain and port identifiers

for dynamic notification of changes in the

Customer’s purchase requests, a field should be

added to the Company’s registration information

that would define/identify how notification would

be delivered to that Company should a transmission

or ancillary purchase request be directed to that

Company as a Seller of a transmission or ancillary

service. The pertinent information would be either

a full HTTP protocol URL defining the protocol,

host name, port, path, resource, etc. information or

a ‘‘mailto:’’ URL with the appropriate mailbox

string. On receipt of any purchase request directed

to that Company as SELLER via either the

‘‘transrequest’’ or ‘‘ancrequest’’ templates, or on

submission of any change in request STATUS to

that Company as SELLER via either the ‘‘transcust’’

or ‘‘anccust’’ templates, a notification message

formatted as documented for the delivery of

notification to the Customer, shall be formatted and

directed to the Seller.’’

85We note that AEP’s proposed procedure

parallels the registration procedure proposed by the

How Group for Phase IA dynamic notification of

transmission customers.

86PECO notes that the Commission has approved

at least one tariff (Wisconsin Electric Power

Company, 80 FERC ¶ 61,299 (1997), reh’g denied

(unpublished order dated November 13, 1997)) that

permits the transmission provider to set deadlines

by which customers must confirm reservations.

87PECO Comments on Phase IA at p. 3.

88See Order No. 888–A, FERC Stats. & Regs.

¶ 31,048 at 30,523–24. Section 17.4 of the Pro

Forma Tariff gives the deadlines for a notice of a

deficient application, section 17.5 of the Pro Forma

Tariff gives the deadline for a response to a

competed application, and section 18.4 of the Pro

Forma Tariff gives the deadline for a determination

of available capability.

request from a customer that a particular

path be posted that way. We are

reluctant to direct such a change at this

time because it would require a redesign

of OASIS. However, the current system

has sufficient flexibility to deal with

this problem on a case-by-case basis

without the need for the Commission to

modify its rules. The OASIS regulations

at § 37.6(b)(1)(i) currently require that

transmission providers post information

pertaining to any path requested by a

transmission customer, and

transmission providers are free to post

additional paths of commercial

interest.79 Thus, if a customer intends to

do business across a system, it can make

a request that the transmission provider

post the path as an ‘‘in and out’’ path

so that a single reservation can cover

transmission passing through the

transmission provider’s system.80

We encourage AEP to pursue its idea

with the How Group, and to consider,

together with the How Group, what

system redesign its proposal would

necessitate, and whether this would be

feasible and cost justified.

3. Comments on Dynamic Notification

of Secondary Market Providers

Phase I OASIS nodes do not actively

notify a potential transmission customer

of information changes such as the

current ATC for a given path or the

status of a pending service request. The

OASIS systems are passive, presenting

information that is current only at the

time when a particular OASIS node is

queried by the customer. To determine

if more current information is posted,

the customer cannot simply ‘‘stay

tuned’’ to the site but must continually

re-query it. In Order No. 889–A, we

noted the passive nature of Phase I

OASIS systems and requested that the

How Group consider adding more

active, dynamic capabilities to OASIS in

Phase II.

In its Phase IA submittal, the How

Group proposes to add some dynamic

capability to facilitate on-line

transmission service negotiations prior

to Phase II, which we are adopting in

this order.81 It proposes that OASIS

nodes automatically notify a customer

when the status of a reservation request

has changed, from ‘‘pending’’ to either

‘‘accepted’’ or ‘‘denied.’’ This would

reduce the number of steps involved in

closing a transmission service deal and

reduce the incidence of unnecessary

polling of OASIS nodes for status

checks.82

AEP notes that a potential competitive

problem exists on OASIS that could be

resolved by modifying and extending

the How Group’s Phase IA dynamic

notification proposal. AEP points out

that a host transmission provider can

gain an advantage by programing its

own OASIS computer system to

automatically notify it about any

customer requests for transmission

service while the host’s competitors

(e.g., resellers of capacity on its

transmission system (secondary sellers)

and sellers of ancillary services to be

used in conjunction with capacity on its

transmission system) would be forced to

query the host’s OASIS node repeatedly

to learn of any requests for the types of

services they offer.83

AEP believes that extending dynamic

notification to secondary market

providers and ancillary service

providers would resolve this

competitive problem. It requests that a

requirement for such additional

dynamic notification be added to the

Phase IA S&CP Document.84

Commission Conclusion

We agree with AEP that its proposed

extension of the dynamic notification

proposal would eliminate a potential

competitive problem. Therefore, we

adopt AEP’s modified dynamic

notification proposal and accordingly

modify § 4.2.8.2—Company Information

and § 4.2.10.3—Dynamic Notification, of

the S&CP Document to permit

secondary market and ancillary services

providers who wish to be automatically

notified, to identify themselves by

merely registering with the transmission

provider.85 However, for purposes of

Phase IA, this extension of dynamic

notification is required only where the

transmission provider has programmed

its computer system for its own

notification. During Phase II, the OASIS

nodes of all transmission providers will

be required to have this capability.

4. Comments on Reservation Time

Limits

PECO requests the establishment of

predetermined deadlines applicable to

all OASIS nodes, by which acceptances

by transmission providers of

transmission service requests and

confirmation by transmission customers

pertaining to their requests must be

made.86 It contends that predetermined

time limits will enable all parties to be

aware of pertinent deadlines. On this

matter, NRECA similarly points out, as

it did for the proposed interim

measures, that the proposed Phase IA

transmission price discount procedures

will work only if transmission providers

respond to requests for transmission

price discounts in a timely manner.87

Commission Conclusion

We note that the Pro Forma Tariff sets

the deadlines applicable to transmission

providers and we are not in this order

modifying those deadlines.88 Also, in

Order No. 889–A, the matter of

deadlines applicable to transmission

customers was reserved for resolution in

Phase II due to our reluctance to specify

confirmation time limits without first

soliciting the views of representative

industry segments. PECO and NRECA,

however, make a compelling argument

that consistent confirmation deadlines

among OASIS nodes are needed before
38894 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

89Order No. 889–A, FERC Stats. & Regs. at

30,574.

90The ‘‘flag’’ would identify whether the

negotiated transmission service price is higher or

lower than a transmission provider’s offering price.

A negotiated price may be higher than the offering

price (not to exceed the ceiling price), for example,

as the result of an auction on a constrained

interface.

91How Group Phase II Report at p. 16.

92Southern Comments on Phase IA at pp. 1–6.

93Southern Comments on Phase IA at p. 2.

Phase II. In addition, the Commercial

Practices Group is now available to

review this matter and give us its

recommendations on how we should

proceed. We, therefore, request that the

Commercial Practices Group examine

the development of proposed Phase IA

deadlines and make recommendations

to us on this issue by August 31, 1998.

F. Data Elements in the Templates Are

To Be Fixed in Sequence and Number,

and Are Not To Differ Among OASIS

Nodes

The How Group asks us to reconsider

our Order No. 889–A clarification that

data elements in OASIS templates must

be fixed in sequence and number, and

are not to differ from OASIS node to

OASIS node. The How Group contends

that this does not permit the

introduction of new fields to existing

templates and it stifles OASIS

innovation by transmission providers.

Commission Conclusion

The Commission continues to believe

that permitting transmission providers

to reorder and add their own

information to OASIS templates defeats

the purpose of standardizing electronic

communication across all OASIS nodes.

Standardization of electronic

communication across all OASIS nodes

is the underlying principle that permits

efficient movement of power across the

grid by making it easier for customers to

locate information in a timely manner

across various OASIS nodes. As we

have stated before, when the industry

proposes modifications to the standards,

we will continue to order revisions to

the S&CP Document, thus implementing

across-the-board changes to the

templates for all OASIS nodes, as

necessary.89 Moreover, even though we

will continue to be responsive to

requests to revise the S&CP Document

as warranted, the proper forum for

challenging issues first decided in Order

No. 889–A (such as this one) would

have been in a timely request for

rehearing of Order No. 889–A.

G. The Meaning of Disclosure of a

Discount Given to a Particular Customer

The How Group asks the Commission

to clarify the definition of what

constitutes a transmission price

‘‘discount.’’ The How Group’s June 27,

1997 letter states that it understands the

Commission’s definition to be any price

below the tariff or ceiling price. The

August 12, 1997 How Group letter

requests clarification that, for the

purpose of requiring disclosure of any

transmission price discount given to a

particular customer, the transmission

price discount should be defined as any

negotiated price different from the offer

price that has been posted on the

OASIS. The How Group proposes to

identify transmission price discounts in

two ways: (1) discounts from the ceiling

price and (2) discounts stemming from

negotiations regardless of whether the

initial offer was the ceiling price. All

discounts would be identified by

posting the discounted price next to the

ceiling price in the offering templates

posted by the transmission provider.

Negotiated discounts would be

identified by a negotiation ‘‘flag’’ in the

TRANSSTATUS template.90 The

negotiation ‘‘flag’’ would enable

searches for discounts given to

particular customers for specific

transmission services, including

searches by path, points of receipt and

delivery, etc.91

Commission Conclusion

We agree with the How Group that,

pursuant to our Order No. 888–A policy,

a transmission price discount is present

whenever a transmission price below

the tariff or ceiling price is offered or

negotiated by a transmission provider.

The proposed use of a negotiation flag,

in addition to the ceiling price and offer

and bid price in the TRANSSTATUS

template, meets our requirement to

disclose transmission price discounts,

identifying both a negotiated

transmission price discount as well as

an initial transmission offer price

positioned below the ceiling price. We

incorporate the How Group’s proposal

in the revised Phase IA S&CP

Document.

H. Date of Implementation for Phase IA

Changes

The How Group proposes an

implementation date for its proposed

Phase IA changes starting six months

after approval by the Commission. This

schedule would provide four months for

development and beta testing and two

months for training and full scale

testing.

Commission Conclusion

We agree with the How Group that the

six-month implementation schedule is

reasonable. Accordingly, we will direct

that the Phase IA changes must be

implemented on December 1, 1998.

I. Impact of Phase IA Implementation

Southern posits that the overall goal

of Phase I should be to ensure a reliable

core set of transmission service

information in a format that is easy to

access and simple to use and that Phase

IA will represent progress only if it has

the effect of making OASIS workable for

the majority of market participants.92

Therefore, the resources of transmission

providers and customers should be

concentrated on making day-to-day

OASIS operations more effective, before

adding new features to OASIS.93

Southern contends that the benefits of

Phase IA are not worth the risk of

market disruption that is sure to be

caused by implementing an interim and

substantially new OASIS. Repeating the

point it made with respect to the

proposed interim measures, Southern

argues that Phase IA on-line

negotiations may add complexity and

will impede rather than accelerate

robust trading of power because it will

burden OASIS without increasing

throughput. It adds that linking

ancillary services to transmission

services further increases the data entry

requirements of the transmission

provider and further increases the data

that must be transferred between the

provider and customer.

Commission Conclusion

As noted, Southern repeats its

contention that interim measures for online negotiations may add complexity

and impede rather than accelerate

robust trading of power because it will

increase the burden of using OASIS

without increasing its throughput.

Nonetheless, the policies that led to the

changes at issue here were adopted by

the Commission in Order No. 889–A

after a full review on rehearing of Order

No. 889. The proper forum to challenge

the Commission’s findings in Order No.

889–A would have been in a timely

request for rehearing of that order. At

this juncture, we are not persuaded to

revise our policies concerning on-line

negotiations and ancillary services.

J. Uniform Formats for Organizational

Charts and Job Descriptions

In American Electric Power Services

Corp., 81 FERC ¶ 61,332 at 62,512

(1997), order on reh’g and clarification,

82 FERC ¶ 61,131 at 61,470–71 (1998),

the Commission required transmission

providers to post organizational charts

and job descriptions on their OASIS
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38895

94 5 U.S.C. 804(2).

1See American Electric Power Service Corporation, et al., 81 FERC ¶ 61,332 (1997), order on reh’g, 82 FERC ¶ 61,131 (1998), reh’g pending. 2See AES Huntington Beach, et al., L.L.C., 83 FERC ¶ 61,100 (1998).

nodes. Currently, transmission

providers use many different software

programs to create and post

organizational charts and job

descriptions including, but not limited

to, Adobe Systems Incorporated’s

portable document format (‘‘PDF’’),

Microsoft Corporation’s ‘‘Word’’, and

hypertext marked language (‘‘HTML’’).

Because the transmission providers

do not provide the organizational charts

and/or job descriptions in standardized

formats, industry participants have

difficulty viewing and downloading the

information. To rectify this problem, we

encourage the industry to reach

consensus on an industry-wide uniform

format, which could be easily obtained

and widely used by industry

participants, to cover both

organizational charts and job

descriptions, or at a minimum, one

uniform format for organizational charts

and another uniform format for job

descriptions. To this end, we request

that the How Group, within 90 days of

the date of issuance of this order,

develop an industry-wide uniform

format for organizational charts and job

descriptions, and submit its

recommendations on this issue to the

Commission.

III. Effective Date and Congressional

Notification

Version 1.1 of the S&CP Document, as

modified herein, will take effect 60 days

from the publication of this order in the

Federal Register. Version 1.2 of the

S&CP Document, as modified herein,

will take effect on December 1, 1998.

The revisions to § 4.3.7.b of Version 1.2

of the S&CP Document, pertaining to the

masking of source and sink information,

will take effect on January 1, 1999.

The Commission has determined,

with the concurrence of the

Administrator of the Office of

Information and Regulatory Affairs of

the Office of Management and Budget,

that this Rule is not a ‘‘major rule’’

within the meaning of section 351 of the

Small Business Regulatory Enforcement

Act of 1996.94 The Commission will

submit the rule to both houses of

Congress and the Comptroller General

prior to its publication in the Federal

Register.

The Commission orders:

(A) The current S&CP Document

(Version 1.1) is hereby modified, as

discussed in the body of this order, to

incorporate the interim procedures on

price negotiation. This directive is to

become effective 60 days from the date

of publication of this order in the

Federal Register. The S&CP Document

(Version 1.1), as modified herein, will

be superseded by the revised S&CP

Document (Version 1.2), as shown on

Attachment 2 to this order, upon the

effective date of the revised S&CP

Document (Version 1.2) ordered below

in Ordering Paragraph (B).

(B) The revised S&CP Document

(Version 1.2), as shown on Attachment

2 to this order, is hereby adopted for use

by Transmission Providers, to become

effective on December 1, 1998, as

discussed in the body of this order.

(C) The revised S&CP Document

(Version 1.2) is hereby modified, as

discussed in the body of this order, to

revise references in § 4.3.7.b pertaining

to the masking of source and sink

information, to become effective on

January 1, 1999.

By the Commission. Commissioner Bailey

dissented in part with a separate statement

attached. Commissioner He ́bert concurred.

David P. Boergers,

Acting Secretary.

BILLING CODE 6717–01–P

Open Access Same-Time Information System and Standards of Conduct

[Docket No. RM95–9–003]

Issued June 18, 1998.

BAILEY, Commissioner, dissenting in part

I respectfully dissent from the decision to require the unmasking of source and sink information and the posting

of such information, for public inspection, on a transmission provider’s open access same-time information system

(OASIS).

In my judgment, this case presents a difficult balancing issue. Specifically, it raises the issue of whether the public

divulgence of (what certain commenters characterize as) commercially and competitively sensitive information is outweighed by the public’s and the Commission’s need for such information for the purpose of detecting possible undue

discrimination or preference in the provision of transmission service.

This issue—the balance between protecting commercially sensitive business information and requiring its disclosure

for the purpose of monitoring and enforcement—is a recurring one. I have previously discussed the issue in the context

of separation of functions requirements applicable to transmission providers 1 and reporting and filing requirements

applicable to power suppliers with market-based rate authority.2

I view this issue as particularly important as wholesale power markets initiate and continue their development

to competitive markets. From a regulator’s perspective, it presents a difficult quandary. Should we require the divulgence

of additional information to promote our monitoring of the competitive market, when we suspect or are informed

that divulgence of such information would act to hinder operation of the very competitive market we are attempting

to foster?

Here, the information at issue is what the order characterizes as ‘‘source and sink’’ information. Source and sink

information helps to define the transmission service. Specifically, it identifies the location of the generation resource

and the location of the load to be served.

This is very important information to the extent it allows the transmission provider to assess the demands a request

for transmission service will place on its transmission system. I want to be clear that I have absolutely no problem

with the divulgence of source and sink information, and any other related information, to the transmission provider

and any other entities, for the purpose of promoting the reliability of the system and implementing appropriate line

loading relief procedures.
38896 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

The question here, however, is very different—whether such information should be made publicly available, by

postings on the OASIS, to the public and to the Commission.

Here, we see different viewpoints on the subject. We are informed that transmission providers are, for the most

part, indifferent on the subject and simply want to be apprised of their OASIS posting obligations in the aftermath

of Order No. 889–A, which required the on-line posting and negotiation of transmission discounts and the unmasking

of party names. (The OASIS ‘‘How’’ Working Group, a representative industry coalition that periodically makes recommendations as to proposed improvements in OASIS procedures and protocols, takes no position on the subject and

simply seeks Commission ‘‘clarification’’ as to whether the unmasking of names also requires the unmasking of source

and sink information.)

Transmission customers, on the other hand, offer strong opinion on the subject. Power marketers and power producers

articulate strong opposition to the OASIS posting of source and sink information. They believe that this information

is commercially and competitively sensitive, and that the public divulgence of the information will stifle the development

of competitive markets (particularly markets for short-term energy transactions) and seriously impair their ability to

act as market intermediaries identifying and matching sellers and purchasers.

Transmission customers without generation for sale offer a different judgment. They believe that the disclosure

of source and sink information, identifying generation and load, will promote transparency of utility operations and

better enable customers and the Commission to detect undue discrimination.

Today’s order strikes a balance in favor of disclosure. It finds that the information is necessary to better enable

customers and the Commission to detect and remedy undue discrimination and preference in the provision of open

access transmission service. It also finds that disclosure is helpful in promoting the accuracy of the numbers—available

transmission capacity (ACT) and total transmission capacity (TTC)—that transmission providers must post on the OASIS.

The order also helps to protect the commercial and competitive sensitivity of source and sink information by delaying

the posting of such information until the time a transmission customer has confirmed that it wishes to finalize the

transaction. In this manner, other transmission providers will not be able to swoop in and pirate off pending transactions,

through the use of source and sink information, while they are still in the process of negotiation. In addition, the

order delays until January 1, 1999 the date by which transmission providers must begin to post on the OASIS the

source and sink information provided by transmission customers.

I find this delay in the public posting of source and sink information to be helpful in mitigating the commercial

and competitive consequences of disclosure. Nevertheless, even with the delay in posting, I remain of the opinion

that the balance tips in favor of protecting commercially and competitively sensitive information against public disclosure.

I base this judgment on several considerations.

First, I remain unconvinced whether the unmasking of this information is necessary or represents the best, or even

an appropriate, method of improving our ability to detect undue discrimination or promote the validity of OASIS

postings. The Electric Power Supply Association, for example, in its comments refers to using source and sink information

for enforcement purposes as ‘‘akin to going after a bug with a cannon instead of a fly swatter.’’ I wonder whether

there are more narrowly-tailored solutions, such as upgrading the data retention or auditing procedures of Order No.

889.

Second, I am struck by the fact that a large segment of the transmission customer community—power marketers

and suppliers—which has an obvious interest in promoting competitive markets and utility compliance with our open

access and OASIS initiatives actually opposes this initiative. To the extent we act to improve our enforcement mechanisms

to the benefit of transmission customers, I would hope to see greater unanimity of support among such purported

beneficiaries. In this regard, the commenters which oppose the unmasking of source and sink information are among

those attendees at our July, 1997 technical conference on OASIS implementation which expressed great concern for

the validity and usefulness of OASIS postings and procedures and urged a number of proposed improvements. However,

unmasking of source and sink information was not one of the improvements advanced for our consideration.

Third, as today’s order recognizes, the Commission itself recently reaffirmed—as recently as March 1997 in Order

No. 888–A—the commercial and competitive sensitivity of source and sink information by providing in the pro forma

transmission tariff that such information would remain confidential, except in certain limited circumstances. What circumstances have transpired in the last year as to defeat the presumption of confidentiality and to compel a reversal

and the disclosure of such information at this time?

Fourth, we have incomplete information upon which to take the significant step of changing our mind and now

unmasking information concerning the location of generation and load. The Commission is advancing an order on

a variation of that which was set for notice and comment last summer. We have not elicited comments on whether

delaying the posting of this information until the time of transaction finalization, or delaying the effectiveness of revisions

to the OASIS Standards and Communications Protocols Document for seven months (until January 1, 1999), is sufficient

to mitigate the competitive concerns of the commenters. The Coalition for a Competitive Market (CCEM) suggests, as

an alternative, that the Commission could balance its concerns by further delaying disclosure of source and sink information for 30 days after a request for service is accepted, denied or withdrawn.

I am basing my decision on the pleadings as compiled in this proceeding. Upon the submission of further comment

(such as in petitions for rehearing) as to the balancing of interests between protecting commercially and competitively

sensitive information and using such information to promote enforcement and monitoring of markets, I could be persuaded

to adopt a different balance.

At this time, however, I believe that the Commission’s very important interest in monitoring markets and protecting

against the abuse of monopoly power by transmission providers does not outweigh the Commission’s interest in protecting

this type of commercially and competitively sensitive information and, thereby, promoting a vigorous and thriving

wholesale power market.

For all of these reasons, I dissent from the decision to require the unmasking of source and sink information

and to adopt revised procedures in the OASIS Standards and Communications Protocols Document to reflect this unmasking of information. I concur in all other respects with the findings of the order.

Vicky A. Bailey,

Commissioner.

Note: This attachment will not appear in the Code of Federal Regulations.
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38897

Attachment 2—Standards and Communication Protocols for Open Access Same-Time Information System (OASIS)

Version 1.2

May 27, 1998

Table of Contents

1. Introduction

1.1 Definition of terms

2. Network Architecture Requirements

2.1 Architecture of OASIS Nodes

2.2 Internet-Based OASIS Network

2.3 Communication Standards Required

2.4 Internet Tool Requirements

2.5 Navigation and Interconnectivity Between OASIS Nodes

3. Information Access Requirements

3.1 Registration and Login Requirements

3.2 Service Level Agreements

3.3 Access to Information

3.4 Provider Updating Requirements

3.5 Access to Changed Information

3.6 User Interaction With an OASIS Node

4. Interface Requirements

4.1 Information Model Concepts

4.2 OASIS Node Conventions and Structures

4.2.1 OASIS Node Naming Requirements

4.2.1.1. OASIS Node Names

4.2.1.2. OASIS Node and Primary Provider Home Directory

4.2.1.3 CGI Script Names

4.2.2 Data Element Dictionary

4.2.3 OASIS Template Constructs

4.2.3.1 Template Construction

4.2.3.2 Template Categories

4.2.3.3 Template HTML Screens

4.2.4 Query/Response Template Requirements

4.2.4.1 Query Requirements

4.2.4.2 Response Requirements

4.2.5 Input/Response Template Requirements

4.2.5.1 Input Requirements

4.2.5.2 Response to Input

4.2.6 Query Variables

4.2.6.1 General

4.2.6.2 Standard Header Query Variables

4.2.6.3 Responses to Queries

4.2.6.4 Multiple Instances

4.2.6.5 Logical Operations

4.2.6.6 Handling of Time Data Elements

4.2.6.7 Default Values

4.2.6.8 Limitations on Queries

4.2.7 CSV Format

4.2.7.1 General Record Format

4.2.7.2 Input Header Records

4.2.7.3 Response Header Records

4.2.7.4 Data Records

4.2.7.5 Continuation Records

4.2.7.6 Error Handling in CSV-Formatted Responses

4.2.8 Registration Information

4.2.8.1 General

4.2.8.2 Company Information

4.2.8.3 User Information

4.2.9 Representation of Time

4.2.9.1 General

4.2.9.2 Input Time

4.2.9.3 Output (Response) Time

4.2.10 Transaction Process

4.2.10.1 Purchase Transactions

4.2.10.2 Status Values

4.2.10.3 Dynamic Notification

4.2.10.3.1 HTTP Notification

4.2.10.3.2 E-mail Notification

4.2.11 Reference Identifiers

4.2.12 Linkage of Ancillary Services to Transmission Services

4.3 Template Descriptions

4.3.1 Template Summary

4.3.2 Query/Response of Posted Services Being Offered

4.3.2.1 Transmission Capacity Offerings Available for Purchase (transoffering)
38898 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

4.3.2.2 Ancillary Services Available for Purchase (ancoffering)

4.3.3 Query/Response of Services Information

4.3.3.1 Transmission Services (transserv)

4.3.3.2 Ancillary Services (ancserv)

4.3.4 Query/Response of Schedules and Curtailments

4.3.4.1 Hourly Schedule (schedule)

4.3.4.2 Curtailment/Interruption (curtail)

4.3.5 Query/Response of Lists of Information

4.3.5.1 List (list)

4.3.6 Query/Response to Obtain the Audit log

4.3.6.1 Audit Log Information (auditlog)

4.3.7 Purchase Transmission Services

4.3.7.1 Customer Capacity Purchase Request (transrequest)

4.3.7.2 Status of Customer Purchase Request (transstatus)

4.3.7.3 Seller Approval of Purchase (transsell)

4.3.7.4 Customer Confirmation of Purchase (Input) (transcust)

4.3.7.5 Alternate Point of Receipt/Delivery (transalt)

4.3.7.6 Seller to Reassign Service Rights to Another Customer (transassign)

4.3.8 Seller Posting of Transmission Services

4.3.8.1 Seller Capacity Posting (transpost)

4.3.8.2 Seller Capacity Modify (transupdate)

4.3.9 Purchase of Ancillary Services

4.3.9.1 Customer Requests to Purchase Ancillary Services (ancrequest)

4.3.9.2 Ancillary Services status (ancstatus)

4.3.9.3 Seller Approves Ancillary Service (ancsell)

4.3.9.4 Customer accepts Ancillary Service (anccust)

4.3.10 Seller Posting of Ancillary Services

4.3.10.1 Seller Ancillary Services Posting (ancpost)

4.3.10.2 Seller Modify Ancillary Services Posting (ancupdate)

4.3.11 Informal Messages

4.3.11.1 Provider/Customer Want Ads and Informal Message Posting Request (messagepost)

4.3.11.2 Message (message)

4.3.11.3 Provider/Sellers Message Delete Request (messagedelete)

4.3.11.4 Personnel Transfers (personnel)

4.3.11.5 Discretion (discretion)

4.3.11.6 Standards of Conduct (stdconduct)

4.4 File Request and File Download Examples

4.4.1 File Example for Hourly Offering

4.4.2 File Example for Hourly Schedule Data

4.4.3 Customer Posting a Transmission Service Offering

4.4.4 Example of Re-aggregating Purchasing Services using Reassignment

4.4.5 File Examples of the Use of Continuation Records

4.4.6 Example of Negotiation of Price

4.4.6.1 Negotiation with Preconfirmation

4.4.6.2 Negotiations without Preconfirmation

4.4.6.3 Multiple Step Negotiations

4.4.6.4 Negotiations Refused by Seller

4.4.6.5 Negotiations Withdrawn by Customer

4.5 Information Supported By Web Page

5. Performance Requirement

5.1 Security

5.2 Access Privileges

5.3 OASIS Response Time Requirements

5.4 OASIS Provider Account Availability

5.5 Backup and Recovery

5.6 Time Synchronization

5.7 TS Information Timing Requirements

5.8 TS Information Accuracy

5.9 Performance Auditing

5.10 Migration Requirements

Appendix A—Data Element Dictionary

ATTACHMENT 1.—ABBREVIATIONS OF NAMES USED IN ORDER

Entity name Abbreviation

Alabama Power Company .............................................................................................................................................. (Alabama Power)

American Electric Power ................................................................................................................................................. (AEP)

American Public Power Association ............................................................................................................................... (APPA)

Central Illinois Lighting Company ................................................................................................................................... (CILCO)

Coalition for a Competitive Electric Market .................................................................................................................... (CCEM)

Commercial Practices Working Group ........................................................................................................................... (Commercial Practices

Group)

Commonwealth Edison Company .................................................................................................................................. (Commonwealth Edison)

Continental Power Exchange ......................................................................................................................................... (CPEX)

Electric Clearinghouse, Inc ............................................................................................................................................. (Electric Clearinghouse)
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38899

ATTACHMENT 1.—ABBREVIATIONS OF NAMES USED IN ORDER—Continued

Entity name Abbreviation

Electric Power Research Institute ................................................................................................................................... (EPRI)

Electric Power Suppliers Association ............................................................................................................................. (EPSA)

Florida Power Corporation .............................................................................................................................................. (Florida Power Corp)

Georgia Power Company ............................................................................................................................................... (Georgia Power)

Gulf Power Company ...................................................................................................................................................... (Gulf Power)

Mississippi Power Company ........................................................................................................................................... (Mississippi Power)

OASIS How Working Group (EPRI) ............................................................................................................................... (How Group)

National Rural Electric Cooperative Association ............................................................................................................ (NRECA)

New York Power Pool ..................................................................................................................................................... (NYPP)

New York State Electric & Gas Corp ............................................................................................................................. (NYSEG)

North American Electric Reliability Council .................................................................................................................... (NERC)

Pennsylvania—New Jersey—Maryland Power Pool ...................................................................................................... (PJM)

PECO Energy Company—Power Team ......................................................................................................................... (PECO)

PECO Energy Company—Power Team and Vitol Gas & Electric, Ltd .......................................................................... (PECO Energy)

Savannah Electric and Power Company ........................................................................................................................ (Savannah)

Southern Company Services, Inc. .................................................................................................................................. (Southern)

1. Introduction

1.1 Definition of Terms

The following definitions are offered to clarify discussions of the OASIS in this document.

a. Transmission Services Information (TS Information) is transmission and ancillary services information that must

be made available by public utilities on a non-discriminatory basis to meet the regulatory requirements of transmission

open access.

b. Open Access Same-Time Information System (OASIS) comprises the computer systems and associated communications facilities that public utilities are required to provide for the purpose of making available to all transmission

users comparable interactions with TS Information.

c. Open Access Same-Time Information System Node (OASIS Node) is a subsystem of the OASIS. It is one computer

system in the (OASIS) that provides access to TS Information to a Transmission Customer.

d. Transmission Provider (TP or Primary Provider) is the public utility (or its designated agent) that owns, operates

or controls facilities used for the transmission of electric energy in interstate commerce. (This is the same term as

is used in Part 35.3).

e. Transmission Customer (TC or Customer) is any eligible Customer (or its designated agent) that can or does

execute a transmission service agreement or can or does receive transmission service. (This is the same term as is

used in Part 35.3).

f. Secondary Transmission Provider (ST, Reseller, or Secondary Provider) is any Customer who offers to sell transmission capacity it has purchased. (This is the same as Reseller in Part 37).

g. Transmission Services Information Provider (TSIP) is a Transmission Provider or an agent to whom the Transmission

Provider has delegated the responsibility of meeting any of the requirements of Part 37. (This is the same as Responsible

Party in Part 37).

h. Value-Added Transmission Services Information Provider (VTSIP) is an entity who uses TS Information in the

same manner as a Customer and provides value-added information services to its Customers.

2. Network Architecture Requirements

2.1 Architecture of OASIS Nodes

a. Permit Use of Any OASIS Node Computers: TSIPs shall be permitted to use any computer systems as an OASIS

Node, so long as they meet the OASIS requirements.

b. Permit Use of Any Customer Computers: OASIS Nodes shall permit the use by Customers of any commonly

available computer systems, as long as they support the required communication links to the Internet.

c. Permit the Offering of Value-Added Services: TSIPs are required, upon request, to provide their Customers the

use of private network connections on a cost recovery basis. Additional services which are beyond the scope of the

minimum OASIS requirements are also permitted. When provided, these private connections and additional services

shall be offered on a fair and non-discriminatory basis to all Customers who might choose to use these services.

d. Permit Use of Existing Communications Facilities: In implementing the OASIS, the use of existing communications

facilities shall be permitted. The use of OASIS communication facilities for the exchange of information beyond that

required for open transmission access (e.g., transfer of system security or operations data between regional control

centers) shall also be permitted, provided that such use does not negatively impact the exchange of open transmission

access data and is consistent with the Standards of Conduct in Part 37.

e. Single or Multiple Providers per Node: An OASIS Node may support a single individual Primary Provider (plus

any Secondary Providers) or may support many Primary Providers.

2.2 Internet-Based OASIS Network

a. Internet Compatibility: All OASIS Nodes shall support the use of internet tools, internet directory services, and

internet communication protocols necessary to support the Information Access requirements stated in Section 4.

b. Connection through the Public Internet: Connection of OASIS Nodes to the public Internet is required so that

Users may access them through Internet links. This connection shall be made through a firewall to improve security.
38900 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

c. Connection to a Private Internet Networks: OASIS Nodes shall support private connections to any OASIS User

(User) who requests such a connection. The TSIP is permitted to charge the User, based on cost, for these connections.

The same internet tools shall be required for these private networks as are required for the public Internet. Private

connections must be provided to all users on a fair and nondiscriminatory basis.

d. Internet Communications Channel: The OASIS Nodes shall utilize a communications channel to the Internet

which is adequate to support the performance requirements given the number of Users subscribed to the Providers

on the Node (see section 5.3).

2.3 Communications Standards Required

a. Point-to-Point Protocol (PPP) and Internet Protocol Control Protocol (IPCP) (reference RFCs 1331 and 1332) shall

be supported for private internet network dial-up connections.

b. Serial Line Internet Protocol (SLIP) (reference RFC 1055) shall be supported for private internet network dialup connections.

c. Transport Control Protocol and Internet Protocol (TCP/IP) shall be the only protocol set used between OASIS

Nodes whenever they are directly interconnected, or between OASIS Nodes and Users using private leased line internet

network connections.

d. Hyper Text Transport Protocol (HTTP), Version 1.0 (RFC 1945), shall be supported by User’s web browsers

so they can use it to select information for viewing displays and for downloading and uploading files electronically.

e. Internet Protocol Address: All OASIS Nodes are required to use an IP address registered with the Internet Network

Information Center (InterNIC), even if private connections are used.

2.4 Internet Tool Requirements

Support the following specific internet tools is required, both for use over the public Internet as well as for any

private connections between Users and OASIS Nodes:

a. Hypertext Markup Language (HTML), at least Version 3.2 shall be used by supported by User’s browsers as

a standards tool for viewing information.

b. HTML Forms shall be provided by the TSIPs to allow Customers to enter information to the OASIS Node.

c. Domain Name Service (DNS) (ref. RFC 1034, 1035) shall be provided as a minimum by the TSIPs (or their

Internet Service Provider) for the resolution of IP addresses to allow Users to navigate easily between OASIS Nodes.

d. Simple Network Management Protocol (SNMP) is recommended but not required to provide tools for operating

and managing the network, if private interconnections between OASIS Nodes are established.

e. The Primary Provider shall support E-mail for exchanges with Customers, including the sending of attachments.

The protocols supported shall include, as a minimum, the Simple Messaging Transfer Protocol (SMTP), Post Office

Protocol (POP(), and Multipurpose Internet Mail Extensions (MIME).

2.5 Navigation and Interconnectivity Between Oasis Nodes

a. World Wide Web Browsers: TSIPs shall permit Users to navigate using WWW browsers for accessing different

sets of TS Information from one Provider, or for getting to TS Information from different Providers on the same OASIS

Node. These navigation methods shall not favor User access to any Provider over another Provider, including Secondary

Providers.

b. Internet Interconnection across OASIS Nodes: Navigation tools shall not only support navigation within the TSIP’s

Node, but also across interconnected OASIS Nodes. This navigation capability across interconnected Nodes shall, as

a minimum, be possible through the public Internet.

3. Information Access Requirements

3.1 Registration and Login Requirements

a. Location of Providers: To provide Users with the information necessary to access the desired Provider, all Primary

Providers shall register their OASIS Node URL address with www.tsin.com. This URL address should include the unique

four letter acronym the Primary Provider will use as the PRIMARYlPROVIDERlCODE.

b. Initial User Registration: TSIPs shall require Users to register with a Primary Provider before they are permitted

to access the Provider’s TS Information. There must be a reference pointing to registration procedures on each Primary

Provider’s home page. Registration procedures may vary with the administrative requirements of each Primary Provider.

c. Initial Access Privileges: Initial registration shall permit a User only the minimum Access Privileges. A User

and a Primary Provider shall mutually determine what access privilege the User is permitted. The TSIP shall set a

User’s Access Privilege as authorized by the Primary Provider.

d. User Login: After registration, Users shall be required to login every time they establish a dial-up connection.

If a direct, permanent connection has been established, Users shall be required to login initially or any time the connection

is lost. Use of alternative forms of login and authentication using certificates and public key standards is acceptable.

e. User Logout: Users shall be automatically loged out any time they are disconnected. Users may logout voluntarily.

3.2 Service Level Agreements

Service Level Agreements: It is recognized that Users will have different requirements for frequency of access, performance, et., based on their unique business needs. To accommodate these differing requirements, TSIPs shall be required

to establish a ‘‘Service Level Agreement’’ with each User which specifies the terms and conditions for access to the

information posted by the Providers. The default Service Level Agreement shall be Internet access with the OASIS

Node meeting all minimum performance requirements.

3.3 Access to Information

a. Display: TSIPs shall format all TS Information on HTML format such that it may be viewed and read directly

by Users without requiring them to download it. This information shall be in clear English as much as possible,
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38901

with the definitions of any mnemonics or abbreviations available on-line. The minimum information that is to be

displayed is provided in the Templates in Section 4.3.

b. Read-Only Access to TS Information: For security reasons, Users shall have read-only access to the TS Information.

They shall not be permitted to enter any information except where explicitly allowed, such as HTML transaction request

forms or by the Templates in Section 4.3.

Downloading Capability: Users shall be able to download from an OASIS Node the TS Information in electronic

format as a file. The rules for formatting of this data are described in Section 4.2.

d. On-Line Data Entry on Forms: Customers shall be permitted to fill out on-line the HTML forms supplied by

the TSIPs, for requesting the purchase of services and for posting of products for sale (by Customers who are resellers).

Customers shall also be permitted to fill-out and post Want-Ads.

e. Uploading Capability: Customers shall be able to upload to OASIS Nodes the filled-out forms. TSIPs shall ensure

that these uploaded forms are handled identically to forms filled out on-line. TSIPs shall provide forms that support

the HTTP input of Comma Separated Variable (CSV) records. This capability shall permit a Customer to upload CSV

records using standard Web browsers or additional client software (such as fetchlhttp) to specify the location of the

CSV records stored on the Customer’s hard disk.

f. Selection of TS Information: Users shall be able to dynamically select the TS Information they want to view

and/or download. This selection shall be, as a minimum, through navigation to text displays, the use of pull-down

menus to select information for display, data entry into forms for initiating queries, and the selection of files to download

via menus.

3.4 Provider Updating Requirements

The following are the Provider update requirements:

a. Provider Posting of TS Information: Each Provider (including Secondary Providers and Value-Added Providers)

shall be responsible for writing (posting) and updating TS Information on their OASIS node. No User shall be permitted

to modify a Provider’s Information.

b. Info.htm: Each Provider shall provide general information on how to use their node and describe all special

aspects, such as line losses, congestion charges and assistance. The address for the directory of this information shall

be info.htm, an HTML web page, linked to the Provider’s registered URL address.

c. OASIS Node Space for Secondary Provider: To permit Users to readily find TS Information for the transmission

systems that they are interested in. TSIPs shall provide database space on their OASIS Node for all Secondary Providers

who have purchased, and who request to resell, transmission access rights for the power systems of the Primary Providers

supported by that Node.

d. Secondary Provider Posting to Primary Provider Node: The Secondary Providers shall post the relevant TS Information on the OASIS Node associated with each Primary Provider from whom the transmission access rights were originally

purchased.

e. Secondary Provider Posting Capabilities: The TSIPs shall ensure that the Secondary Providers shall be able to

post their TS Information to the appropriate OASIS Nodes using the same tools and capabilities as the Customers,

meet the same performance criteria as the Primary Providers, and allow users to view these postings on the same

display page, using the same tables, as similar capacity being sold by the Primary Providers.

f. Free-Form Posting of non-TS Information. The TSIP shall ensure that non-TS Information such as Want-Ads,

may be posted by Providers and Customers, and that this information is easily accessible by all Users. The TSIP

shall be allowed to limit the volume and/or to charge for the posting of non-TS Information.

g. Time Stamps: All TS Information shall be associated with a time stamp to show when it was posted to the

OASIS Node.

h. Transaction Tracking by an Assignment Reference Number: All requests for purchase of transmission or ancillary

services will be marked by a unique accounting number, called an assignment reference.

i. Time-Stamped OASIS Audit Log: All posting of TS Information, all updating of TS Information, all User logins

and disconnects, all User download requests, all Service Requests, and all other transactions shall be time stamped

and stored in an OASIS Audit Log. This OASIS Audit Log shall be the official record of interactions, and shall be

maintained on-line for download for at least 90 days. Changes in the values of posted Capacity (Available Transfer

Capability) must be stored in the on-line audit Log for 20 days. Audit records must be maintained for 3 years offline and available in electronic form within seven days of a Customer request.

j. Studies: A summary description with dates, and programs used of all transmission studies used to prepare data

for the Primary Provider’s ATC and TTC calculation will be provided along with information as to how to obtain

the study data and results.

3.5 Access to Changed Information

a. General Message & Log: TSIPs shall post a general message and log that may be read by Users. The message

shall state that the Provider has updated some information, and shall contain (or point to) a reverse chronological

log of those changes. This log may be the same as the Audit Log. The User may use the manual capability to see

the message.

b. TSIP Notification Design Responsibilities: The TSIP shall avoid a design that could cause serious performance

problems by necessitating frequent requests for information from many Users.

3.6 User Interaction With an OASIS Node

There are three basic types of User interactions which must be supported by the OASIS Node. These interactions

are defined in Section 4.3.

a. Query/Response: The simplest level of interactions is the query of posted information and the corresponding

response. The User may determine the scope of the information queried by specifying values, through an HTML form,
38902 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

a URL string, or an uploaded file, using Query Variables and their associated input values as defined with each Template

in Section 4.3. The response will be either an HTML display or a record oriented file, depending on the output

format that the User requests.

The TSIP may establish procedures to restrict the size of the response, if an overly broad query could result in

a response which degrades the overall performance of the OASIS Node for their Users.

b. Purchase Request: The second type of Customer interaction is the submittal of a request to purchase a service.

The Customer completes an input form, a URL string or uploads a file and submits it to the OASIS Node. The uploaded

file can either be a series of query variables or a record oriented file.

The request is processed by the Seller of the service, possibly off-line from the OASIS Node, and the status is

updated accordingly.

If a purchase request is approved by the Seller, then it must be again confirmed by the Customer. Once the Customer

confirms an approved purchase, a reservation for those services is considered to exist, unless later the reservation

is reassigned, displaced, or annulled.

c. Upload and Modify Postings: Customers who wish to resell their rights may upload a form, create the appropriate

URL or upload a file to post services for sale. A similar process applies to eligible Third Party Sellers of ancillary

services. The products are posted by the TSIP. The seller may monitor the status of the services by requesting status

information. Similarly the Seller may modify its posted transmission services by submitting a service modification request

through a form, a URL query, or by uploading a file.

4. Interface Requirements

4.1 Information Model Concepts

a. ASCII-Bases OASIS Templates: For providing information to Users, TSIPs shall use the specified OASIS Templates.

These Templates define the information which must be presented to Users, both in the form of graphical displays

and as downloaded files. Users shall be able to request Template information using query-response data flows. The

OASIS Templates are described in section 4.3. The Data Element Dictionary, which defines the data elements in the

OASIS Templates, is provided in Appendix A.

Data elements must be used in the exact sequence and number as shown in the Templates when file uploads

and downloads are used. Although the contents of the graphical displays are precisely defined as the same information

as in the Templates, the actual graphical display formats of the TS information are beyond the scope of the OASIS

requirements. Due to the nature of graphical displays, there may be more than one graphical display used to convey

the information in a single Template.

b. ASCII-Based OASIS File Structures: For uploading requests from and downloading information to Users, TSIPs

shall use specific file structures that are defined for OASIS Template information (see section 4.2). These file structures

are based on the use of headers which contain the Query Variable information, including the name of the OASIS

Template. These headers thus determine the contents and the format of the data follows. Although headers may not

be essential if file transfers contain the exact sequence and number of data elements as the Templates, this feature

is being preserved for possible future use when additional flexibility may be allowed.

4.2 OASIS Node Conventions and Structures

4.2.1 OASIS Node Naming Requirements

The following naming conventions shall be used to locate information posted on OASIS. OASIS naming conventions

shall conform to standard URL structures.

4.2.1.1 OASIS Node Names

In order to provide a consistent method for locating an OASIS Node, the standard Internet naming convention

shall be used. All OASIS Node names shall be unique. Each Primary Provider OASIS Node name and home directory

shall be registered with the master OASIS directory site at http://www.tsin.com. OASIS Node names shall be stored

in an Internet DNS name directory.

4.2.1.2 OASIS Node and Primary Provider Home Directory

The home directory name on an OASIS Node shall be ‘‘OASIS’’ to identify that the directory is related to the

OASIS. The directory of each Primary Provider shall be listed under the ‘‘OASIS’’ directory:

http://(OASIS Node name)/OASIS/(PRIMARYlPROVIDERlCODE)

Where:

(OASIS Node name) is the World Wide Web URL address of the OASIS Information Provider.

(PRIMARYlPROVIDERlCODE is the 4 character acronym of the primary provider.

(PRIMARYlPROVIDERlCODEs shall be registered with the master OASIS directory site at http://www.tsin.com.

A pointer to user registration information shall be located on the Primary Provider’s home page.

4.2.1.3 CGI Script Names

Common Gateway Interface (CGI) scripts shall be located in the directory ‘‘data’’ as follows:

http://(OASIS Node name)/OASIS/(PRIMARYlPROVIDERlCODE)/data/(cgi script name)?(query variables)

Where:

(cgi script name) is the OASIS Template name (see Section 4.3). Other cgi scripts may be defined as required

to implement the HTML interface to the documented templates. (query variables) is a list of query variables with

their settings formatted as defined by the HTTP protocol (i.e., URL encoded separated by ampersands).
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38903

Example:

To request the hourly schedule Template at Primary Provider WXYZ Co. http://www.wxyz.com/oasis/wxyz/data/schedule

?templ=schedule& ver=1.2& fmt=data & stime=19960412040000PD &sptime=19960412100000PD& pprov=wxyz

4.2.2 Data Element Dictionary

The following are the requirements for the Data Element Dictionary:

a. Definition of OASIS Information Elements: All OASIS Information data elements shall be defined in the Data

Element Dictionary which will be stored in the OASIS Node directory:

http://(OASISNode Name)/OASIS/(PRIMARYlPROVIDERlCODE/ (datadic.html 1 datadict.txt)

Where:

datadic.html is the HTML version of the data element dictionary

datadic.txt is the ASCII text version of the data element dictionary

The Data Element Dictionary is defined in Appendix A.

b. Provider-specific Data Element Values: The valid values that certain OASIS Information data elements may take

on, such as PATHlNAME, etc., are unique to a Primary Provider. Names which must be uniquely identified by Primary

Provider shall be listed on-line on the OASIS Node via the LIST Template (see Section 4.3.5). In posting OASIS information

associated with data elements which are not free-form text, TSIPs shall use only the accepted data element values

listed in the Data Element Dictionary and/or those values posted in the LIST of provider specific names provided

on the OASIS.

4.2.3 OASIS Template Constructs

4.2.3.1 Template Construction

Section 4.3 lists the set of OASIS Templates that shall be supported by all OASIS nodes. These OASIS Templates

are intended to be used precisely as shown for the transfer of data to/from OASIS, and identify, by Data Elements

names, the information to be transferred. The construction of the OASIS Templates shall follow the rules described

below:

a. Unique OASIS Template Name: Each type of OASIS Template shall be identified with a unique name which

shall be displayed to the User whenever the OASIS Template is accessed.

b. Transfer Protocol: OASIS Templates are transferred using the HTTP protocol. Templates shall support both the

‘‘GET’’ and ‘‘POST’’ methods for transferring ‘‘query string’’ name/value pairs, as well as the OASIS specific ‘‘comma

separated value’’ (CSV) format for posting and retrieval of information from OASIS. HTML screens and forms shall

be implemented for each OASIS Template.

c. Source Information: Each OASIS Template shall identify the source of its information by including or linking

to the name of the Primary Provider, the Secondary Provider, or the Customer who provided the information.

d. Time Of Last Update: Each OASIS Template shall include a time indicating when it was created or whenever

the value of any Data Element was changed.

e. Data Elements: OASIS Templates shall define the elementary Data Element Dictionary names for the data values

to be transferred or displayed for that Template.

f. Documentation: OASIS Information shall be in non-cryptic English, with all mnemonics defined in the Data Element

Dictionary or a glossary of terms. TSIPs shall provide on-line descriptions and help screens to assist Users understanding

the displayed information. Documentation of all formats, contents, and mnemonics shall be available both as displays

and as files which can be downloaded electronically. In order to meet the ‘‘User-Friendly’’ goal and permit the flexibility

of the OASIS to expand to meet new requirements, the OASIS Templates shall be as self-descriptive as possible.

4.2.3.2 Template Categories

OASIS Templates are grouped into the following two major categories:

a. Query/Response: These Templates are used to query and display information posted on OASIS. Each query/

response Template accepts a set of user specified Query Variables and returns the appropriate information from data

posted on OASIS based on those query variables. The valid Query Variables and information to be returned in response

are identified by Data Element in Section 4.3.

b. Input/Response: These Templates are used to upload/input information on OASIS. The required input information

and information to be returned in response are identified by Data Element in Section 4.3, Template Descriptions.

4.2.3.3 Template HTML Screens

Though the exact form and content of the HTML screens and forms associated with the OASIS Templates are

not dictated by this document, the following guidelines shall be adhered to for all HTML screens and forms implemented

on OASIS:

a. Data Element Headings: Data displayed in an HTML screen/form shall be labeled such that the associated data

value(s) is(are) easily and readily identifiable as being associated with a particular OASIS Template Date Element.

HTML ‘‘Hot-Links’’ or other pointer mechanisms may be provided for Data Element headings in OASIS Templates

which permit the User to access documentation describing the meaning, type, and format of the associated data.

b. Display Limitations: HTML screens and forms shall be implemented in such a way to allow the display of

all data specified for each OASIS Template. This may take the form of ‘‘wrapping’’ of lines of information on the

screen, the use of horizontal and/or vertical scrolling, or the use of ‘‘Hot-Links’’ or other pointer mechanisms. There

is not necessarily a one-to-one relationship between OASIS implemented HTML screens and their associated Template.

However, all Template data elements shall be viewable through one or more HTML screens.

c. Template Navigation: HTML ‘‘Hot-Links’’ or other pointer mechanisms may be provided to assist the navigation

between screens/forms associated with related OASIS Templates.
38904 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

4.2.4 Query/Response Template Requirements

Retrieval of information posted on OASIS is supported by the Query/Response Templates. The ‘‘query’’ identifies

the OASIS Template and optionally supplies additional Data Elements which may be used to select specific information

to be returned in the ‘‘response’’.

4.2.4.1 Query Requirements

Query information is transferred to OASIS using the HTML protocol as a string of Query Variables in the form

of name/value pairs. Query Variable name/value pairs are specified as a collection encoded strings (e.g., blank characters

replaced by plus (+) character, etc.) in the form of name=value, with each name/value pair separated by ampersands

(&) (see section 4.2.6). OASIS shall support the following methods for Users to input Query information:

a. HTML: HTML FORM input and/or hypertext links shall be provided to allow Users to specify OASIS Template

Query Variables. This will be the easiest way to obtain information should be the choice of most causal Users and

for simple requests. The exact nature and form of these HTML screens are not specified, and may differ between

OASIS nodes.

b. GET Method: The HTML GET method for specifying query information appended to a standard OASIS URL

shall be supported. Using this method, the name=value formatted Query Variables preceded by a question mark (?)

are appended to the URL. Each ‘‘name’’ in a name/value pair corresponds to a Data Element name associated with

that Template, OASIS shall support the specification of all Data Elements associated with a Template by both their

full name and alias as defined in the Data Dictionary. The ‘‘value’’ in a name/value pair represents the value to

be associated with the Data Element being specified in the appropriate format as defined in the Data Dictionary and

encoded according to the HTML protocol.

c. POST Method: The HTML POST method for specifying query information in the message body shall be supported.

Using this method, the name=value formatted Query Variables shall be transferred to OASIS suing the ‘‘Content-length:’’

HTML header to define the length in bytes of the encoded query string and the ‘‘Content-type: application/x-wwwform-urlencoded’’ HTML header to identify the data type included in the message body. Each ‘‘name’’ in a name/

value pair corresponds to a Data Element name associated with that Template. OASIS shall support the specification

of all Data Elements associated with a Template by both their full name and alias as defined in the Data Dictionary.

The ‘‘value’’ in a name/value pair represents the value to be associated with the Data Element being specified in

the appropriate format as defined in the Data Dictionary and encoded according to the HTML protocol.

User queries using any of the above methods are supported directly by the User’s web browser software. More

sophisticated data transfer mechanisms, such as the automated querying of information based on Query Variable strings

contained in a User data file (i.e., ‘‘uploading a file containing a URL string), require appropriate software (e.g.,

‘‘fetchlhttp’’) running on the User’s computer system to effect the data transfer.

4.2.4.2 Response Requirements

In response to a validly formatted Query for each Query/Response OASIS Template, the OASIS shall return the

requested information in one of two forms based on the User specified OUTPUTlFORMAT Query Variable:

a. HTML: If the User requests the response to have the format of ‘‘HTML’’ (OUTPUTlFORMAT=HTML) then the

response from the OASIS shall be a web page using the HTML format. This shall be the default for all Query/Response

Templates.

b. CSV Format: Comma Separated Value (CSV) format (OUTPUTlFORMAT=DATA) returns the requested information

in the body of the HTML response message. The ‘‘Content-length:’’ HTML header shall define the length in bytes

of the response, and the ‘‘Content-type: text/x-oasis-csv’’ HTML header shall be used to identify the data type included

in the message body (see CSV File Format).

4.2.5 Input/Response Template Requirements

The posting of information on OASIS, including reservations for transmission/ancillary service, services for sale

on the secondary market, etc., is supported by the Input/Response Templates. The ‘‘input’’ identifies the required data

associated with an OASIS Template to be posted on OASIS, and the ‘‘response’’ specifies the information returned

to the User.

4.2.5.1 Input Requirements

Input information is transferred to OASIS using the HTTP protocol as either a string of Query Variable in the

form of name/value pairs, or as a Comma Separated Value (CSV) message. Query Variable name/value pairs are specified

as a collection of encoded strings (e.g., blank characters replaced by plus (+) character, etc.) in the form of name=value,

with each name/value pair separated by ampersands (&). CSV formatted messages are specified in the body of an

HTTP message as a series of data records preceded by a fixed set of header records (see section 4.2.7).

OASIS shall support the following methods for Users to transfer Input data:

a. HTML: HTML FORM input shall be provided to allow Users to specify the necessary Input data associated

with each Input/Response OASIS Template. This may be in the form of fill in blanks, buttons, pull-down selections,

etc., and may use either the GET or POST methods. The exact nature and form of these HTML screens are not specified,

and may differ between OASIS nodes.

b. GET Method: The HTTP GET method for specifying Input information in the form of a query string appended

to a standard OASIS URL shall be supported. Using this method, the name=value formatted Query Variables preceded

by a question mark (?) are appended to the URL. Each ‘‘name’’ in a name/value pair corresponds to a Data Element

name associated with that Template. OASIS shall support the specification of all Data Elements associated with a

Template by both their full name and alias as defined in the Data Dictionary. The ‘‘value’’ in a name/value pair

represents the value to be associated with the Data Element being specified in the appropriate format as defined in

the Data Dictionary and encoded according to the HTTP protocol.
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38905

c. POST Method: The HTTP POST method for specifying Input information in the form of a query string in the

message body shall be supported. Using this method, the name-value formatted Query Variables shall be transferred

to OASIS using the ‘‘Content-length:’’ HTTP header to define the length in bytes of the encoded query string and

the ‘‘Content-type: application/x-www-form-urlencoded’’ HTTP header to identify the data type included in the message

body. Each ‘‘name’’ in a name/value pair corresponds to a Data Element name associated with that Template. OASIS

shall support the specification of all Data Elements associated with a Template by both their full name and alias

as defined in the Data Dictionary. The ‘‘value’’ in a name/value pair represents the value to be associated with the

Data Element being specified in the appropriate format as defined in the Data Dictionary and encoded according to

the HTTP protocol.

d. CSV Format: Comma Separated Value (CSV) formatted Input information transferred in the body of a User’s

HTTP message shall be supported. The ‘‘Content-length:’’ HTTP header shall define the length in bytes of the Input,

and the ‘‘Content-type: text/x-oasis-csv’’ HTTP header shall be used to identify the data type included in the message

body.

4.2.5.2 Response to Input

In response to a validly formatted Input for each Input/Response OASIS Template, the OASIS shall return an indication

as to the success/failure of the requested action. The OASIS shall respond to the Input in one of two forms, based

on the OUTPUTlFORMAT, which was input by a User either as a Query Variable or in a CSV format Header Record:.

a. HTML: If the User requests the response to have the format of ‘‘HTML’’ (OUTPUTlFORMAT=HTML) then the

response from the OASIS shall be a web page using the HTML format. This shall be the default for all Input/Response

Templates invoked using either the FORM, GET or POST methods of input.

b. CSV Format: Coma Separated Value (CSV) format (OUTPUTlFORMAT=DATA) returns the response information

in the body of the HTTP response message. The ‘‘Content-length:’’ HTTP header shall define the length in bytes of

the response, and the ‘‘Content-type: text/x-oasis-csv’’ HTTP header shall be used to identify the data type included

in the message body. This shall be the default for all Input/Response Templates invoked using the CSV Format methods

of input.

4.2.6 Query Variables

4.2.6.1 General

Both Query/Response and Input/Response OASIS Templates shall support the specification of a query string consisting

of Query Variables formatted as name/value pairs. OASIS shall support the specification of Data Element names (‘‘name’’

portion of name=value pair) in both the full name and alias forms defined in the Data Dictionary. OASIS shall support

the specification of Query Variables from the User using either the HTTP GET or POST methods. On input, Data

Element names and associated values shall be accepted and processed without regard to case. On output, Data Element

names and associated values may not necessarily retain the input case, and could be returned in either upper or

lower case.

4.2.6.2 Standard Header Query Variables

The following standard Query Variable Data Elements shall be supported for all OASIS Templates and must be

entered for each Query by a User:

VERSION

TEMPLATE

OUTPUTlFORMAT

PRIMARYlPROVIDERlCODE

PRIMARYlPROVIDERlDUNS

RETURNlTZ

Since these header Query Variables must be supported for all Templates, they are not listed explicitly in the Template

description in Section 4.3.

All standard header Query Variables with appropriate values must be entered by the User.

4.2.6.3 Responses to Queries

Responses to Queries will include the following information as a minimum:

TIMElSTAMP

VERSION

TEMPLATE

OUTPUTlFORMAT

PRIMARYlPROVIDERlCODE

PRIMARYlPROVIDERlDUNS

RETURNlTZ

The additional information shall include:

a. The requested information as defined by the Template indicated in the Query.

b. For CSV downloads, the additional header Data Elements required (see section 4.2.7.3).

4.2.6.4 Multiple Instances

Certain Query Variables may be repeated in a given Query/Response OASIS Template query string. Where such

multiple instances are documented in the Template definitions using an asterix (*) after the query variable. When

more than one instance of the query Variable is specified in the query string, OASIS shall recognize such multiple

instances by either the Data Element’s full name or alias suffixed with sequential numeric qualifiers starting with
38906 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

the number 1, (e.g., PATHlNAME1=abc&PATHlNAME2=xyz, or PATH1=abc&PATH2=xyz). At least 4 multiple instances

will be permitted for each query variable marked with an asterix (*).

4.2.6.5 Logical Operations

OASIS shall use the following logical operations when processing Query Variables for Query/Response OASIS Templates. All Query Variables, with the exception of multiple instances of the same Query Variable Data Element, shall

be operated on to return information based on the logical-AND of those Query Variables. For example, the query string

‘‘...SELLERlCODE=abc&PATH=xyz...’’ should return information associated with only those records that are on transmission path ‘‘xyz’’ AND associated with transmission provider ‘‘abc.’’ Multiple instances of the same Query Variable

shall be operated on as logical-OR. For example,’’... SELLERlCODE=abc&PATH1=xyz&PATH2=opq...’’ should return information associated with transmission provider ‘‘abc’’ AND either transmission path ‘‘xyz’’ OR transmission path ‘‘opq’’.

Some logical operations may exclude all possibilities, such that the responses may not contain any data.

4.2.6.6 Handling of Time Data Elements

In cases where a single query variable is provided to select information associated with a single template data

element that represents a point in time (e.g., TIMElOFlLASTlUPDATE), OASIS shall return to the User all requested

information whose associated data element time value (e.g. TIMElOFlLASTlUPDATE) is equal to or later than the

value specified by the query variable. In this case the stop time is implicitly ‘‘now’’.

A pair of query variables (e.g. STARTlTIMElQUEUED and STOPlTIMElQUEUED) that represents the start and

stop of a time interval but is associated with one single template data element (e.g. TIMElQUEUED shall be handled

by OASIS to return to the User all requested information whose associated data element time value falls within the

specified time interval.

A pair of query variables (e.g. STARTlTIME and STOPlTIME query variables) that represents the start and stop

of one time interval but is associated with another pair of template data elements (e.g. STARTlTIME and STOPlTIME

of a service offering) that represents a second time interval, shall be handled by OASIS to return to the User all

requested information whose associated data element time interval overlaps any portion of the specified time interval.

Specifically, the STARTlTIME query variable selects all information whose STOPlTIME data element value is later

than the STARTlTIME query variable, and the STOPlTIME query variable selects all information whose STARTlTIME

data element value is earlier than the STOPlTIME query variable. For example:

The transoffering template query string ‘‘STARTlTIME 970101000000ES&STOPlTIME970201000000ES’’ shall select from

the OASIS database all associated offerings whose start/stop times overlap any portion of the time from 00:00 January

1, 1997, to 00:00 February 1, 1997. This would include offerings that (1) started prior to Jan. 1 and stopped any

time on or after Jan. 1, and (20 started on or after Jan. 1 but before Feb. 1

For changes to and from daylight savings time, either Universal Time or the correct time and zone must be used,

based on whether daylight savings time is in effect.

All Time values shall be checked upon input to ensure their validity with respect to date, time, time zone, and

daylight savings time.

4.2.6.6 Default Values

Query Variables that are not specified by the User may take on default values as appropriate for that Query Variable

at the discretion of the OASIS TSIP.

4.2.6.8 Limitations on queries

OASIS TSIP may establish validation procedures and/or default values for Query Variables to restrict the size and/

or performance impact of overly broad queries.

4.2.7 CSV Format

4.2.7.1 General Record Format

OASIS Users shall be able to upload information associated with Input/Response OASIS Templates and download

information associated with all OASIS Templates using a standardized Comma Separated Value (CSV) format. CSV

formatted data is transferred to/from OASIS as part of the body of an HTTP message using the ‘‘Content-length:’’ HTTP

header to define the length in bytes of the message body, and the ‘‘Content-type: text/x-oasis-csv’’ HTTP header to

identify the data type associated with the message body. CSV formatted data consists of a fixed set of header records

followed by a variable number of data records. Each record shall be separated by a carriage return plus line feed

(denoted by the symbol ↵ in all examples). The fields within a record shall be delimited by commas(,). All data

within a CSV formatted message shall use printable ASCII characters with no other special embedded codes, with

the exception of the special encoding requirements associated with text fields.

4.2.7.2 Input Header Records

The following standard header records are required for the uploading of Input data for all Input/Response OASIS

Templates:

VERSION-nn.nTM

TEMPLATE=aaaaaaaaaaTM

OUTPUTlFORMAT=[DATA]TM

PRIMARYlPROVIDERlCODE=aaaaTM

PRIMARYlPROVIDERlDUNS=nnnnnnnnnTM

RETURNlTZ=aaTM
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38907

DATAlROWS=nnnTM

COLUMNlHEADERS=[Template data element names separated by commas]TM

The format of the value associated with each of the Input header record Data Elements are dictated by the Data

Dictionary.

The value associated with the DATAlROWS Data Elements shall define the total Number of data records that

follow in the message after the COLUMNlHEADERS record.

The COLUMNlHEADERS record defines, by Data Element name, the data associated with each comma separated

column contained in each subsequent data record (row). On Input, either the Data Element’s full name or alias listed

in the Data Dictionary may be specified.

4.2.7.3 Response Header Records

When explicitly specified using the OUTPUTlFORMAT=DATA Query Variable or implied by the Input of a CSV

format message, the OASIS shall respond with the following standard response header records for all OASIS Templates:

REQUESTlSTATUS=nnnTM

ERRORlMESSAGE=aaa...TM

TIMElSTAMP=yyyymmddhhmmsstzTM

VERSION=nn.nTM

TEMPLATE=aaaaaaaaaaTM

OUTPUTlFORMAT=DATETM

PRIMARYlPROVIDERlCODE=aaaaTM

PRIMARYlPROVIDERlDUNS=nnnnnnnnnTM

RETURNlTZ=tzTM

DATAlROWS=nnnTM

COLUMNlHEADERS=[Template data element names separated by commas]TM

The format of the value associated with each of the Response header record Data Elements are dictated by the

Data Dictionary.

The value associated with the DATAlROWS Data Element shall define the total number of data records returned

in the message following the COLUMNlHEADERS header record.

The COLUMNlHEADERS record defines, by Data Element name, the data associated with each comma-separated

column contained in each subsequent data record (row). In all OASIS responses, the Data Element’s full name shall

be listed in the COLUMNlHEADERS record. The order of the column headings shall be the same as shown in the

Templates for URL uploads and downloads. For graphical displays, the Provider may define the order that the Data

Element names are shown.

4.2.7.4 Data Records

Data Records immediately follow the standard Input or Response header records. With the exception of data records

grouped together as a single ‘‘logical record’’ through the use of Continuation Records, each data record in a CSV

formatted Input message represents a single, complete execution of the associated OASIS Template. That is, sending

five CSV formatted Input messages for a given Template to the same PRIMARYlPROVIDERlCODE with a single data

record per message shall be handled in the exactly the same fashion as sending a single CSV formatted Input message

for the same Template and PRIMARYlPROVIDERlCODE which contains five data records.

Each field (column) within each data record defines the value to be associated with the corresponding Data Element

defined in the COLUMlHEADERS record. The number of Data Records in the message is defined by the DATAlROWS

header record. The data values associated with each column Data Element are interpreted based on the Data Element

type as defined in the Data Dictionary:

a. Numeric Data Element: All numeric Data Elements shall be represented by an ASCII string of numeric digits

in base ten, plus the decimal point.

b. Text Data Elements: Alphabetic and alphanumeric data elements shall be represented as ASCII strings and encoded

using the following rules:

• Text strings that do not contain commas (,) or double quotes (‘‘) shall be accepted both with and without being

enclosed by double quotes.

• Text fields with commas (,) or double quotes (‘‘) must be enclosed with double quotes. In addition double quotes

within a text field shall be indicated by two double quotes (‘‘‘‘).

• The Data Element field length specified in Data Dictionary does not include the additional double quotes necessary

to encode text data.

a. Null Data Elements: Null Data Elements shall be represented by two consecutive commas (,,) corresponding to

the leading and trailing (if appropriate) Data Element commas separators. Null text strings may optionally be represented

by two consecutive double quote characters within the leading and trailing comma separators (i.e., ...,’’’’,...).

4.2.7.5 Continuation Records

Continuation records shall be used to indicate that the information in multiple rows (records) is part of one logical

record. Continuation records will be indicated through the use of a column header called CONTINUATIONlFLAG.

This column header is either the first column (if in a response to a query) or second column (if in a response to

an input) in all Templates permitting continuation records. The first record shall contain a ‘‘N’’ in the CONTINUATIONlFLAG column and each following record which is part of a continuation record shall contain a ‘‘Y’’ in this

column, thus associating the information in that record with the information in the previous record. An ‘‘N’’ shall

indicate that the record is not a continuation record. Any values corresponding to COLUMNlHEADERS other than

those explicitly allowed for a particular Template shall be ignored. However commas must be included to properly

align the fields.
38908 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

4.2.7.6 Error Handling in CSV-Formatted Responses

Validity of each record in the CSV-formatted Response to a Template Input shall be indicated through the use

of RECORDlSTATUS and ERRORlMESSAGE Data Elements which are included in each data record (row) of the

Response.

• If no error was encountered in an Input data record, the RECORDlSTATUS Data Element in the corresponding

Response record shall be returned with a value of 200 (success), and the ERRORlMESSAGE shall be blank.

• If any error is detected in processing an Input data record, it shall be indicated by a RECORDlSTATUS Data

Element value other than 200. The ERRORlMESSAGE shall be set to an appropriate text message to indicate the

source of the error in that data record.

The overall validity of each Template Query or Input shall be indicated in the CSV-formatted Response via the

two REQUESTlSTATUS and ERRORlMESSAGE header records (see section 4.2.7.3):

• If no errors were encountered in processing the User’s Input data records, the REQUESTlSTATUS shall be returned

with the value of 200 (success), and the ERRORlMESSAGE shall be blank.

• If any errors were detected in the Template Input data records, the REQUESTSlSTATUS value shall be any

value other than 200, and the ERRORlMESSAGE shall be set to an appropriate text message to indicate the source

of the error.

The OASIS node shall validate all Input records before returning a Response to the User. All valid records shall

be processed by the node, while invalid records shall be identified as erroneous through the use of RECORDlSTATUS

and ERRORlMESSAGE. The User must correct the invalid fields and resubmit only those records which were invalid.

If an error is encountered in a record which is part of a set of Continuation records, then all records belonging to

that set must be resubmitted.

4.2.8 Registration Information

4.2.8.1 General

As specified in the Information Access Requirements. OASIS Nodes shall provide a mechanism to register Users

of the OASIS with a Provider. For all levels of access to OASIS information beyond simple read-only access. OASIS

node shall provide a mechanism to identify Users of the OASIS at least to the level of their respective Companies.

Both Company and User registration information shall be maintained by the OASIS node.

4.2.8.2 Company Information

OASIS Templates require that certain Company registration information be maintained. As an extension of the Company

registration information of the host, domain and port identifiers for dynamic notification of changes in the Customer’s

purchase requests, a field should be added to the Company’s registration information that would define/identify how

notification would be delivered to that Company should a transmission or ancillary purchase request be directed to

that Company as a Seller of a transmission or ancillary service. The pertinent information would be either a full

HTTP protocol URL defining the protocol, host name, port, path, resource, etc. information or a ‘‘mailto:’’ URL with

the appropriate mailbox address string. On receipt of any purchase request directed to that Company as SELLER via

either the ‘‘transrequest’’ or ‘‘ancrequest’’ templates, or on submission of any change in request STATUS to that Company

as SELLER via either the ‘‘transcust’’ or ‘‘anccust’’ templates, a notification message formatted as documented for the

delivery of notification to the Customer, shall be formatted and directed to the Seller. At a minimum, OASIS shall

maintain the following information for each Company:

a. Company Code: 4 character code for primary transmission providers; 6 character code for eligible customers

in accordance with NERC Tagging Information System (TIS) requirements shall be maintained for each Company.

b. Default Contact: Unless specified for each individual user affiliated with the Company, default contact information

consisting of a phone number, fax number, and e-mail address shall be maintained for each Company.

c. Provider Affiliation: Each eligible Customer shall be obligated to identify to the OASIS TSIP any affiliation with

a Transmission Provider whose ‘‘home page’’ is on that OASIS node.

d. Notification URL: For Companies using the URL notification mechanism for delivery of messages on each change

of ancillary/transmission reservation STATUS, each Company shall provide the IP host name and port number to be

used in delivering notification messages. OASIS nodes shall have the right to refuse support for notification to any

IP ports other than port 80.

4.2.8.3 User Information

With the exception of ‘‘read-only’’ (visitor) access. OASIS nodes shall as a minimum provide a mechanism to identify

Users of the node with at least their Company. However, OASIS nodes and Providers shall have the right to require

full User identification even for visitor accounts.

To support the required OASIS Template Data Elements, OASIS nodes shall maintain the following information

for each registered User:

• Company

• Name

• Phone

• Fax

• E-mail

In the event no additional additional User identification/registration information is maintained by the OASIS, all

Template Data Elements referring to ‘‘company, name, phone, fax, e-mail’’ for either Customers or Sellers shall default

to the Contact Information maintained for that User’s Company.

4.2.9 Representation of Time

4.2.9.1 General

It is critical that all Users of OASIS have a clear and unambiguous representation of time associated with all

information transferred to/from OASIS. For this reason, all Data Elements associated with time in OASIS shall represent
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38909

‘‘wall clock’’ times, which are NOT to be confused with other common industry conventions such as ‘‘hour ending.’’

For the convenience of the User community, OASIS nodes shall be allowed to accept the input and display of ‘‘time’’

in any acceptable form provided such non-standard representations are CLEARLY labeled on the associated HTML

screens. Alternate representations of time in CSV formatted messages shall not be allowed.

The following rules shall be implemented in OASIS for the representation of time on User entries (Query and

Input) and output (Response) Templates.

4.2.9.2 Input Time

All time related Data elements associated with either the Input or Query of Input/Response or Query/Response

OASIS Templates shall be validated according the following rules. If the time zone associated with a time Data Element

is associated with either Universal Time (UT) or a ‘‘standard’’ time zone (e.g., ES, CS, etc.), OASIS shall accept and

apply a fixed hour offset form Universal Time year-round. If the time zone associated with a time Data Element is

specified with a ‘‘daylight savings’’ time zone (e.g. ED, CD, etc.), OASIS shall verify that daylight savings time is

in effect of the date/time specified.

If daylight savings time (as specified by the time from 2:00 am on the first Sunday of October) is not in effect,

the Users input shall be rejected with an error response. If daylight savings time is in effect, the Users input shall

be accepted and the appropriate hours offset from Universal Time shall be applied by OASIS for conversion to all

other time zones. The input of start/stop times fro transactions spanning the crossover day between standard and daylight

(and vices versa) times must be made either entirely in standard time (valid year-round), or in two different time

zones (xS/xD or xD/xS) for the start and stop times, depending on the time of year.

4.2.9.3 Output (Response) Time

The OASIS shall return a shall return all time Data Elements in the response to Input/Response or Query/Response

OASIS Templates based on either the User specified RETURNlTZ header Query Variable or an appropriate OASIS

specific default. OASIS shall interpret RETURNlTZ to specify:

a. The base time zone for conversion of all time Data Elements (e.g. Eastern, Pacific, etc.)

b. Whether daylight savings time is recognized. For example, a RETURNlTZ=ES would return all time Data Elements

in Eastern Standard Time year-round. However, a RETURNlTZ=ED would direct OASIS to return all time Data Elements

in Eastern Standard Time (ES) when daylight savings time is not in effect, and then return all time Data Elements

in Eastern Daylight Time (ED) when daylight time is in effect.

4.2.10 Transaction Process

4.2.10.1 Purchase Transactions

Customers shall purchase services from the Seller using the following steps (see Exhibit 4–1);

a. The Templates (transrequest and ancrequest) shall be used by a Customer to enter a request for specific transmission

services from a specific Seller. The Customer may enter a BIDlPRICE which is different from the OFFERlPRICE

in order to try to negotiate a lower price. The OASIS sets the initial STATUS of the request to QUEUED. The Customer

may set the STATUSlNOTIFICATION to indicate that the OASIS must notify the Customer on any change of STATUS

of transstatus (see Dynamic Notification). Prior to or commensurate with a Seller’s setting of a preconfirmed reservation

request’s STATUS to ACCEPTED (and by implication CONFIRMED), the Seller must set OFFERlPRICE equal to the

value of BIDlPRICE as established by the Customer on submission of the request.

b. The Templates (transstatus and ancstatus) shall be used by Customers and Sellers to monitor the status of their

transactions in progress. These Templates shall also be used by any Users to review the status of any transactions.

The NEGOTIATEDlPRICElZFLAG data element is set when the Seller agrees to a BIDlPRICE (by setting OFFERlPRICE

equal to BIDlPRICE that is different from the previously posted price. It will show ‘‘higher’’ when OFFERlPRICE

is higher than the posted price, and ‘‘lower’’when the OFFERlPRICE is lower than the posted price.

c. The Templates (transsell and ancsell) shall be used by both to set a new value into STATUS and to negotiate

a price by entering a new OFFERlPRICE which is different from the BIDlPRICE entered by the Customer in the

transrequest Template (if it was not PRECONFIRMED). During these negotiations, a Reseller shall formally indicate

the approval or disapproval of a transaction and indicate which rights from prior confirmed reservations are to be

reassigned. A Primary Provider may, but it not required, to enter transaction approval or disapproval using this Template.

The valid STATUS values which may be set by a Seller are: RECEIVED, STUDY, OFFER, ACCEPTED, REFUSED, DISPLACED, ANNULLED, or RETRACTED.

d. The Customer shall use the transstatus and ancstatus Templates to view the Seller’s new offer price and/or

approval/disapproval decision.

e. After receiving notification of the transaction’s STATUS being set to ‘‘OFFER’’ by the Seller the Templates (transcust

and anccust) shall be used by the Customer to modify the BIDlPRICE and set the STATUS to REBID. After negotiations

are complete (STATUS set to ‘‘ACCEPTED’’ by the Seller), the Customer shall formally enter the confirmation or withdrawal

of the offer to purchase services for the OFFERlPRICE shown in the transstatus Template. The valid STATUS values

which a Customer may set are: REBID, CONFIRMED, or WITHDRAWN.

f. The Seller shall use the transstatus (ancstatus) Template to view the Customer’s new bid price and/or confirmation/

withdrawal decision, again responding through transsell or ancsell if necessary. If the Seller offers to sell a service

at an OFFERlPRICE less than the posted in the transoffering (ancoffering) Template, the transoffering (ancoffering)

Template must be updated to reflect the new OFFERlPRICE.

g. For deals consummated off the OASIS by a Seller, after the Customer has accepted the offering, the Templates

(transassign and ancassign) may be used by the Seller to notify the Primary Provider of the transfer of rights to the

Customer. Continuation records may be used to indicate the reassigning of rights for a ‘‘profile’’ of different assignments

and different capacities over different time periods.
38910 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

h. The source of all user and seller contact information shall be the User registration process. Therefore, it shall

not be input as part of uploads, but shall be provided as part of all transaction downloads.

i. OASIS shall accept a seller initiated change in STATUS to ACCEPTED only when OFFERlPRICE matches

BIDlPRICE (i.e., seller must set OFFERlPRICE equal to BIDlPRICE prior to or coincident with setting STATUS to

accepted)

j. OASIS shall accept a customer initiated change in STATUS to CONFIRMED only when BIDlPRICE matches

OFFERlPRICE (i.e. customer must set BIDlPRICE equal to OFFERlPRICE prior to or coincident with setting STATUS

to confirmed).

4.2.10.2 Status Values

The possible STATUS values are:

QUEUED=initial status assigned by TSIP on receipt of ‘‘customer services purchase request’’

RECEIVED=assigned by TP to acknowledge QUEUED requests and indicate the service request is being evaluated, including

for completing the required ancillary services

STUDY=assigned by TP to indicate some level of study is required or being performed to evaluate service request

OFFER=assigned by TP to indicate that a new OFFERlPRICE is being proposed

REBID=assigned by TC to indicate that a new BIDlPRICE is being proposed

ACCEPTED=assigned by TP to indicate service request at the designed OFFERlPRICE has been approved/accepted.

Of the reservation request was submitted PRECONFIRMED, OASIS shall immediately set the reservation status

to CONFIRMED. Depending upon the type of ancillary services required, the Seller may or may not require

all ancillary service reservation to be completed before accepting a request.

REFUSED=assigned by TP to indicate service request has been denied, SELLERlCOMMENTS should be used to communicate reason for denial of service

CONFIRMED=assigned by TC in response to TP posting ‘‘ACCEPTED’’ status, to confirm service. Once a request has

been ‘‘CONFIRMED’’, a transmission service reservation exists

WITHDRAWN=assigned by TC any point in request evaluation to withdraw the request from any further action

DISPLAY=assigned by TP when a ‘‘CONFIRMED’’ reservation from a TC is displaced by a longer term request and

the TC has exercised right of first refusal (i.e. refused to match terms of new request)

ANNULLED=assigned by TP when, by mutual agreement with the TC, a confirmed reservation is to be voided

RETRACTED=assigned by TP when the TC fails to confirm or withdraw the request within the required time period

BILLING CODE 6717–01–M
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38911

BILLING CODE 6716–01–C
38912 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

4.2.10.3 Nynamic Notification

Customers may specify the delivery of dynamic notification messages on each change in STATUS of an ancillary

or transmission service reservation. OASIS shall support the delivery of dynamic notification messages through either

the HTTP protocol or by electronic mail. The selection of which mechanism is used and the contents of the messages

delivered to the client program or e-mail address is defined by the content of the STATUSlNOTIFICATION data

element as described in the next subsections.

Regardless of whether this dynamic notification method is used or not, it shall still remain the User’s responsibility

to get the desired information, possibly through the use of a periodic ‘‘integrity request’’. OASIS nodes shall not be

obligated or liable to guarantee delivery/receipt of messages via the STATUSlNOTIFICATION mechanism other than

on a ‘‘best effort’’ basis.

As an extension of the Company registration information of the host, domain and port identifies for dynamic notification of changes in the Customer’s purchase requests, a field should be added to the Company’s registration information

that would define/identify how notification would be delivered to that Company should a transmission or ancillary

purchase request be directed to that Company as a Seller of a transmission or ancillary service. The pertinent information

would be either a full HTTP protocol URL defining the protocol, host name, port, path, resource, etc. information

or a ‘‘mailto:’’ URL with the appropriate mailbox address string. On receipt of any purchase request directed to that

Company as SELLER via either the ‘‘transrequest’’ or ‘‘ancrequest’’ templates, or on submission of any change in request

STATUS to that Company as SELLER via either the ‘‘transcust’’ or anccust’’ templates, a notification message formatted

as documented for the delivery of notification to the Customer, shall be formatted and directed to the Seller.

4.2.10.3.1 HTTP Notification

OASIS shall deliver dynamic notification to a client system based on HTTP URL information supplied in part

by the STATUS NOTIFICATION data element and by information supplied as part of the Customer’s Company registration

information. HTTP URL’s are formed by the concatenation of a protocol field (i.e., http:), a domain name (e.g., //

www.tsin.com), a port designation (e.g., :80), and resource location information.

The STATUSlNOTIFICATION data element shall contain the protocol field ‘‘http:’’, which designates the notification

method/protocol to be used, followed by all resource location information required; the target domain name and port

designations shall be inserted into the notification URL based on the Customer’s Company registration information.

The resource location information may include directory information, cgi script identifiers and URL encoded query

string name/value pairs as required by the Customer’s application. OASIS performs no processing on the resource location

information other than to include it verbatim along with the protocol, domain name and port information when forming

the URI that will be used to deliver the HTTP protocol notification message.

For example, Company XYZ has established the domain name and port designations of ‘‘//oasistc.xyz.com:80’’ as

part of their registration information.

When a transmission reservation is submitted by one of Company XYZ’s users (the Customer), and includes a

STATUSlNOTIFICATION data element with the value of ‘‘http:/cgi-bin/status? DEALlREF=8&REQUESTlREF=173’’,

OASIS shall deliver and HTTP notification message using the URL: http://oasistic.xyz.com:80/cgi-bin/status?

DEALlREF=8&REQUESTlREF=173

If the STATUSlNOTIFICATION field contained only the ‘‘http:’’ protocol designation, the notifcation message would

be deliverd using the URL: http://oasistc.xyz.com:80

The contents of the HTTP protocol notification message delivered by OASIS shall consist of the complete URL

created by combining fields from the STATUSlNOTIFICATION data element and Company registration information

as part of an HTTP GET method request. In addition to the GET method HTTP header record, OASIS shall also

append the CSV formatted output of the transstatus template information for that particular reservation using the standard

Content-type: text/x-oasis-csv and appropriate Content-length: HTTP header record. OASIS shall use a Primary Provider

specific default value for RETURNlTZ in formulating the transstatus response information.

Continuing with the previous example, the important records in the HTTP notification message that would be delivered

to Company XYZ for the transmission reservation request submitted to Primary Provider ABC and give an ASSIGNMENTlREF of 245 would be,

GET http://oasistc.xyz.com:80chi-bin/status? DEALlREF=8&REQUESTlREF=173 HTTP/1.0

Content-type: text/x-oasis-csv

Content-length: <byte count of remainder of message>

REQUESTlSTATUS=200

TIMElSTAMP=<appropriate value>

VERSION=1.2

TEMPLATE=transstatus

OUTPUTlFORMAT=DATA

PRIMARYlPROVIDERlCODE=ABC

PRIMARYlPROVIDERlDUNS=123456789

RETURNlTZ=<appropriate value for ABC>

DATAlROWS=1

COLUMNlHEADERS=CONTINUATIONlFLAG, ASSIGNMENTlREF, . . .

N, 245, . . .

In the event an error is encountered delivering the HTTP notification message to the target URL as indicated by

a failure of the target system to respond, or return of HTTP response status of 408, 500, 503, and 504, OASIS shall

retry up to two more times, once every 5 minutes.

4.2.10.3.2 E-mail Notification

OASIS shall deliver dynamic notification to an e-mail address based to Mailto: URL information specified in the

STATUSlNOTIFICATION data element. Mailto: URL’s consist of the ‘‘mailto:’’ protocol identifier and an Internet mail
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38913

address to which the notification message should be sent. The STATUSlNOTIFICATION data element shall contain

the protocol field ‘‘mailto:’’, which designates the notification method/protocol to be used, followed by an Internet

mail address in conformance with RFC 822. OASIS shall send an e-mail message to the Internet mail address containing

the following information: ‘‘To:’’ set to the mail address from the STATUSlNOTIFICATION data element, ‘‘From:’’

set to an appropriate mail address of the OASIS node, ‘‘Subject:’’ shall be the transstatus template name followed

by the value of the ASSIGNMENTlREF data element and the current value for the STATUS data element associated

with the reservation (e.g., ‘‘Subject: transstatus 245 ACCEPTED’’), and the body of the message shall contain the CSV

formatted output of the transstatus template information for that particular reservation. OASIS shall use a Primary

Provider specific default value for RETURNlTZ in formulating the transstatus response information.

4.2.11 Reference Identifiers

The TSIP shall assign a unique reference identifier, ASSIGNMENTlREF, for each Customer request to purchase

capacity or services. The value of ASSIGNMENTlREF may be used to imply the order in which the request was

received by the TSIP. This identifier will be used to track the request through various stages, and will be kept with

the service through out its life. Whenever the service is resold, a new ASSIGNMENTlREF number is assigned, but

previous ASSIGNMENTlREF numbers are also kept so that a chain of all transactions related to the service can be

maintained.

The TSIP shall assign a unique reference identifier. POSTINGlREF, to each Seller’s offerings of service for sale

or other information (messages) posted on OASIS. This identifier shall be referenced by the Seller in any/all subsequent

template submissions which would result in a modification to or deletion of that specific offering or message. Optionally,

Customers may also refer to this POSTINGlREF in their subsequent purchase requests to aid in identifying the specific

offering associated with the purchase request.

Sellers may aggregate portions of several previous transmission service reservations to create a new offering to

be posted on OASIS. When all or a portion of such offerings are sold, the Seller (original Customer) is obligated

to notify the Primary Provider of the sale/assignment by inserting appropriate reassignment information on OASIS (via

the transsell or transassign templates) or by some other approved method. This reassignment information consists of

the ASSIGNMENTlREF value assigned to the original reservation(s) and the time interval and capacity amount(s) being

reassigned to the new reservation. These values are retained in the REASSIGNEDlREF, REASSIGNEDlSTARTlTIME,

REASSIGNEDlSTOPlTIME, and REASSIGNEDlCAPACITY data elements.

Sellers may identify their service offerings received from Customers through the Seller supplied value specified

for the SALElREF data element.

Customers may track their purchase requests through the Customer supplied values specified for the DEALlREF

and REQUESTlREF data elements. Customers may also use POSTINGlREF and SALElREF in their purchase requests

to refer back to posted offerings.

4.2.12 Linking of Ancillary Services to Transmission Services

The requirements related to ancillary services are shown in transoffering (and updated using transupdate) using

the ANClSVClREQ data element containing the following permitted values:

SC:x; RV:x; RF:x; EI:x; SP:x; SU:x;

Where SC, RV, RF, EI, SP and SU are the ancillary services 1 through 6 described in the Proforma Tariff.

• SC-Scheduling, system Control and dispatch

• RV-Reactive supply and Voltage control

• RF-Regulation and Frequency response

• EI-Energy Imbalance

• SP-Spinning reserve

• SU-Supplemental reserve

and where x-(M,R,O,U) means one of the following:

• Mandatory, which implies that the Primary Provider must provide the ancillary service

• Required, which implies that the ancillary service is required, but not necessarily from the Primary Provider

• Optional, which implies that the ancillary service is not necessarily required, but could be provided

• Unknown, which implies that the requirements for the ancillary service are not known at this time

Ancillary services may be requested by a User from the Provider at the same time as transmission services are

requested via the transrequest template, by entering the special codes into ANClSVClLINK to represent the Proforma

ancillary services 1 through 6 (or more) as follows:

SC:(AA); RV:(AA); RF:(AA EI: (AA[:xxx[:yyy[:nnn]]]);

SP:(AA[:xxx[:yyy[:nnn]]]); SU:(AA[:xxx[:yyy[:nnn]]]);

Registered :(AA[:xxx[:yyy[:nnn]]])

Where AA is the appropriate PRIMARYlPROVIDERlCODE, SELLERlCODE, or CUSTOMERlCODE, and represents

the company providing the ancillary services. ‘‘AA’’ may be unspecified for ‘‘xxx’’ type identical to ‘‘FT’’, in which

case the ‘‘:’’ character must be present and precede the ‘‘FT’’ type.

If multiple ‘‘AA’’ terms are necessary, then each ‘‘AA’’ grouping will be enclosed within parenthesis, with the

overall group subordinate to the ANClSVClTYPE specified within parenthesis.

And where xxx represents either:

—‘‘FT’’ to indicate that the Customer will determine ancillary services at a future time, or

—‘‘SP’’ to indicate that the Customer will self-provide the ancillary services, or

—‘‘RQ’’ to indicate that the Customer is asking the OASIS to initiate the process for making an ancillary services

reservation with the indicated Provider or Seller on behalf of the Customer. The Customer must then continue
38914 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

the reservation process with the Provider or Seller. If the transmission services request is for preconfirmed service,

then the ancillary services shall also be preconfirmed, or

—‘‘AR’’ to indicate an assignment reference number sequence follows.

The terms ‘‘yyy’’ and ‘‘nnn’’ are subordinate to the xxx type of ‘‘AR’’. yyy represents the ancillary services reservation

number (ASSIGNMENTlREF) and nnn represents the capacity of the reserved ancillary services. Square brackets are

used to indicated optional elements and are not used in the actual linkage itself. Specifically, the :yyy is applicable

to only the ‘‘ARA’’ term and the :nnn may optionally be left off if the capacity of ancillary services is the same

as for the transmission services, and optionally multiple ancillary reservations may be indicated by additional

(xx[:yyy[:nnn]]) enclosed within parenthesis. If no capacity amount is indicated, the required capacity is assumed to

come from the ancillary reservations in the order indicated in the codes, on an ‘‘as-needed’’ basis.

Examples

Example 1

Assume ancillary services SC and RV are mandatory from the TP, whose code is ‘‘TPEL’’, and ancillary services

RF, EI, SP and SU are required, but will be defined at a future time.

‘‘SC: (TPEL:RQ); RV: (TPEL:RQ); RF:(:FT); EI:(:FT); SP:(:FT); SU:(:FT)’’

Example 2

Assume ancillary services SC and RV are mandatory from the TP, whose code is ‘‘TPEL’’, and RF, EI, SP and

SU are self-supplied. The customer code is ‘‘CPSE’’

‘‘SC: (TPEL:RQ); (TPEL:RQ); RF:(CPSE:SP); EI:(CPSE:SP); SP:(CPSE:SP); SU:(CPSE:SP)’’

Example 3

Assume ancillary services SC and RV are mandatory from the TP, whose code is ‘‘TPEL’’, and ancillary services

RF, EI, SP and SU were purchased via a prior OASIS reservation from seller ‘‘SANC’’ whose reservation number was

‘‘39843’’. There is sufficient capacity within the Ancillary reservation to handle this Transmission reservation.

‘‘SE:(TPEL:RQ); RV:(TPEL:RQ); RF:(SANC:AR:39843); EI:(SANC:AR:39843) SP:(SANC:AR:39843); SU:(SANC:AR:39843)’’

Example 4

Assume ancillary services SC and RV are mandatory from the TP, whose code is ‘‘TPEL’’, and ancillary services

RF, EI, SP and SU were purchased via prior OASIS reservations from sellers ‘‘SANC’’ and ‘‘TANC’’, whose reservation

numbers where ‘‘8763’’ and 9824’’ respectively. There is not sufficient capacity within the Ancillary reservation from

seller ‘‘SANC’’ to handle this Transmission reservation. In this case the OASIS reservation number 8763 will be depleted

for the time frame specified within the transmission reservation and the remaining required amount will come from

reservation number ‘‘9824’’.

‘‘SC:(TPEL:RQ); RV:(TPEL:RQ); RF:((SANC:AR:8763)(TANC:AR:9824)); EI:((SANC:AR:8763)(TANC:AR:9824));

SP:((SANC:AR:8763)(TANC:AR:9824)); SU:((SANC:AR:8763)(TANC:AR:9824))’’

Example 5

Assume a transmission reservation in the amount of 100 mw/hour for a period of one day is made. Ancillary

services SC and RV are mandatory from the TP, whose code is ‘‘TPEL’’, and ancillary services RF, EI, SP and SU

were purchased via prior OASIS reservations from sellers ‘‘SANCS’’ and ‘‘TANC’’, whose reservation numbers where

‘‘8763’’ and 9824’’ respectively. There is sufficient capacity within the Ancillary reservation from seller ‘‘SANC’’ to

handle this Transmission reservation, however the purchaser wishes to use only ‘‘40 mw’s’’ for the time frame specified

within the transmission reservation and the remaining required amount will come from reservation number ‘‘9824’’.

‘‘SC:(TPEL:RQ); RV:(TPEL:RQ); RF:((SANC:AR:8763:40)(TANC:AR:9824)); EI:((SANC:AR:8763:40)(TANC:AR:9824));

SP:((SANC:AR:8763:40)(TANC:AR:9824)); SU:((SANC:AR:8763:40)(TANC:AR:9824))’’

4.3 Template Descriptions

The following OASIS Templates define the Data Elements in fixed number and sequence which must be provided

for all data transfers to and from the OASIS modes. The definitions of the data elements are listed in the Data Element

Dictionary in Appendix A.

TSIPs must provide a more detailed supplemental definition of the list of Sellers, Paths, Point of Receipt (POR),

Point of Delivery (POD), Capacity Types, Ancillary Services Types and Templates on-line, clarifying how the terms

are being used (see LIST Template). If POR and POD are not used, then Path Name must include directionality.

Many of the Templates represent query-response interactions between the User and the OASIS Node. These interactions

are indicated by the ‘‘Query’’ and ‘‘Response’’ section respectively of each Template. Some, as noted in their descriptions,

are Input information, sent from the User to the OASIS Node. The Response is generally a mirror of the Input, although

in some Templates, the TSIP must add some information.

4.3.1 Template Summary

The following table provides a summary of the process areas, and Templates to be used by Users to query information

that will be downloaded or to upload information to the Primary Providers. These processes define the functions that

must be supported by an OASIS Node.
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38915

Process area Process name Template(s)

4.3.2 Query/Response of Posted Services Being Offered .... Query/Response Transmission Capacity Offerings ................. transoffering

Query/Response Ancillary Service Offerings .......................... ancoffering

4.3.3 Query/Response of Services Information ..................... Query/Response Transmission Services ................................. transserv

Query/Response Ancillary Services ........................................ ancser

4.3.4 Query/Response of Schedules and Curtailments ........ Query/Response Transmission Schedules .............................. schedule

Query/Response Curtailments ................................................. curtail

4.3.5 Query/Response of Lists of Information ....................... Query/Response List of Sellers, Paths, PORs, PODs, Capacity Types, Ancillary Service Types, Templates.list

4.3.6 Query/Response of Audit Log ...................................... Query/Response Audit Log ...................................................... auditlog

4.3.7 Purchase Transmission Services ................................. Request Purchase of Transmission Services (Input) .............. transrequest

Query/Response Status of Transmission Service Request .... transstatus

Seller Approves Purchase (Input) ............................................ transsell

Customer Confirm/Withdraw Purchase of Transmission Service (Input).transcust

Alternate POD/POR ................................................................. transalt

Seller Reassign Rights (Input) ................................................. transassign

4.3.8 Seller Posting of Transmission Service ........................ Seller Post Transmission Service for Sale (Input) ................... transpost

Seller Modify (Remove) Transmission Service for Sale

(Input).

transupdate

4.3.9 Purchase of Ancillary Service ....................................... Request Purchase of Ancillary Service (Input) ........................ ancrequest

Query/Response Status of Ancillary Service Request ............ ancstatus

Seller Approves Purchase of Ancillary Service (Input) ............ ancsell

Customer Accept/Withdraw Purchase of Ancillary Service

(Input).

anccust

4.3.10 Seller Post Ancillary Service ...................................... Seller Post Ancillary Service (Input) ........................................ ancpost

Seller Modify (Remove) Ancillary Service for Sale (Input) ...... ancupdate

4.3.11 Informal Messages ..................................................... Post Want Ads (Input) ............................................................. messagepost

Query/Response Want Ads ..................................................... message

Delete Want Ad (Input) ............................................................ messagedelete

Personnel Transfers ................................................................. personnel

Discretion ................................................................................. discretion

Personnel Transfers ................................................................. personnel

Standards of Conduct .............................................................. stdconduct

4.3.2 Query/Response of Posted Services Being Offered

The following Templates define the information to be posted on services offered for sale. All discounts for service

negotiated by a Customer and Primary Provider (as Seller) at a price less than the currently posted offering price

shall be posted on OASIS in such a manner as to be viewed using these Templates. All secondary market and/or

third-party posting and Primary Provider offerings for like services shall also be viewed using these templates.

The Query must start with the standard header Query Variable Data Elements, listed in Section 4.2.6.2, and may

include any valid combination of the remaining Query Variables, shown below in the Templates. STARTlTIME and

STOPlTIME is the requested time interval for the Response to show all offerings which intersect that interval (see

Section 4.2.6.6). TIMElOFlLASTlUPDATE can be used to specify all services updated since a specific point in

time.

Query variable listed with an asterisk (*) can be at last 4 multiple instances defined by the user in making the

query.

In the Response, OFFERlSTARTlTIME and OFFERlSTOPlTIME indicate the ‘‘request time window’’ within which

a customer must request a service in order to get the posted OFFERlPRICE. STARTlTIME and STOPlTIME indicate

the time frame that the service is being offered for.

The SERVICElDESCRIPTION data element shall define any attributes and/or special terms and conditions applicable

to the offering that are not listed under the standard SERVICElDESCRIPTION associated with the product definition

supplied in the transserv or ancserv templates.

SERVICElDESCRIPTION shall be null if there are no unique attributes or terms associated with the offering.

4.3.2.1 Transmission Capacity Offerings Available for Purchase (transoffering)

Transmission Services Offerings Available for Purchase (transoffering) is used to offer transmission services that

are posted for sale by the Primary Provider or Resellers. At a minimum this Template must be used to post TTC

and each increment and type of service by applicable regulations and the Primary Provider’s tariffs.

This Template must include, for each posted path, the Primary Provider’s TTC, firm ATC and non-firm ATC, as

required by FERC orders 888 and 889 (plus revisions) and/or if provided in the Primary Provider’s tariff. Additional

transmission services may be offered with the same Template.

The POSTINGlREF is set by the TSIP when an offering is posted and can be used in transrequests to refer to

a particular offering.

A User may query information about services available from all sellers for the time frame specified by the SERVICElINCREMENT data element, namely, hourly, daily, weekly, monthly, or yearly.

Template: transoffering

1. Query

PATHlNAME*
38916 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

SELLERlCODE*

SELLERlDUNS*

POINTlOFlRECEIPT*

POINTlOFlDELIVERY*

SERVICElINCREMENT*

TSlCLASS*

TSlTYPE*

TSlPERIOD*

STARTlTIME (of transmission services)

STOPlTIME (of transmission services)

POSTINGlREF

TIMElOFlLASTlUPDATE

2. Response

The response is one or more records showing the requested service information. Note that the Customer will receive

as a series of records spanning all the SELLERlCODEs, PATHlNAMEslPORs, PODs, TSlxxx, and the STARTlTIME/

STOPlTIME specified in the query. The SALElREF is a value provided by the SELLER to identify the transmission

service product being sold. The ANClSVClREQ indicates all ancillary services required for the specified transmission

services. All Template elements are defined in the Data Element Dictionary.

TIMElOFlLASTlUPDATE

SELLERlCODE

SELLERlDUNS

PATHlNAME

POINTlOFlRECEIPT

POINTlOFlDELIVERY

INTERFACElTYPE

OFFERlSTARTlTIME

OFFERlSTOPlTIME

STARTlTIME

STOPlTIME

CAPACITY

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlWINDOW

TSlSUBCLASS

ANClSVClREQ

SALElREF

POSTINGlREF

CEILINGlPRICE

OFFERlPRICE

PRICElUNITS

SERVICElDESCRIPTION (if null, then look at transserv)

NERClCURTAILMENTlPRIORITY

OTHERlCURTAIMENTlPRIORITY

SELLERlNAME

SELLERlPHONE

SELLERlFAX

SELLERlEMAIL

SELLERlCOMMENTS

4.3.2.2 Ancillary Services Available for Purchase (ancoffering)

Ancillary Services Available for Purchase (ancoffering) is used to provide information regarding the ancillary services

that are available for sale by all sellers (both Primary Provider and Third Party Sellers).

Template: ancoffering

1. Query

SELLERlCODE

SELLERlDUNS

CONTROLlAREA

SERVICElINCREMENT

ANClSERVICElTYPE

STARTlTIME

STOPlTIME

POSTINGlREF

TIMElOFlLASTlUPDATE

2. Response

TIMElOFlLASTlUPDATE
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38917

SELLERlCODE

SELLERlDUNS

CONTROLlAREA

OFFERlSTARTlTIME

OFFERlSTOPlTIME

STARTlTIME

STOPlTIME

CAPACITY

SERVICElINCREMENT

ANCILLARYlSERVICElTYPE

SALElREF

POSTINGlREF

CEILINGlPRICE

OFFERlPRICE

PRICElUNITS

SERVICElDESCRIPTION (if blank, then look at ancserv)

SELLERlNAME

SELLERlPHONE

SELLERlFAX

SELLERlEMAIL

SELLERlCOMMENTS

4.3.3 Query/Response of Services Information

4.3.3.1 Transmission Services (transserv)

Transmission Services (transserv) is used to provide additional information regarding the transmission services SERVICElINCREMENT, TSlCLASS, TSlTYPE, TSlPERIOD, TSlSUBCLASS, TSlWINDOW,

NERClCURTAIMENTlPRIORITY, and OTHERlCURTAIMENTlPRIORITY that are available for sale by a Provider

in the Templates in Section 4.3.2. This Template is used to summarize Provider tariff information for the convenience

of the User. The Provider also sets PRICElUNITS with this Template.

Template: transserv

1. Query

TIMElOFlLASTlUPDATE

2. Response

TIMElOFlLASTlUPDATE

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlWINDOW

TSlSUBCLASS

CEILINGlPRICE

PRICElUNITS

SERVICElDESCRIPTION

NERClCURTAILMENTlPRIORITY

OTHERlCURTAILMENTlPRIORITY

TARIFFlREFERENCE

4.3.3.2 Ancillary Services (ancserv)

Ancillary Services (ancserv) is used to provide additional information regarding the ancillary services that are available

for sale by a Provider in the Templates in Section 4.3.2. This Template is used to summarize Provider tariff information

for the convenience of the User. The Provider also sets PRICElUNITS with this Template.

Template: ancserv

1. Query

TIMElOFlLASTlUPDATE

2. Response

TIMElOFlLASTlUPDATE

SERVICElINCREMENT

ANClSERVICElTYPE

CEILINGlPRICE

PRICElUNITS

SERVICElDESCRIPTION

TARIFFlREFERENCE
38918 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

4.3.4 Query/Response of Schedules and Curtailments

4.3.4.1 Hourly Schedule (schedule)

Hourly Schedule (schedule) is used to show what a Provider’s scheduled transmission capacity usage actually was

for specific Paths. All the information provided is derived from that in the transmission reservation (see Template

transstatus), except CAPACITYlSCHEDULED, which is the amount of the reservation which was scheduled. Posting

of the schedules is organized around the transmission reservations, not the energy schedules. This may require the

Primary Provider to map schedules back to the reservation. These records would have to be created for all reservations/

schedules done off the OASIS during the operations scheduling period.

Template: schedule

1. Query

PATHlNAME*

SELLERlCODE*

SELLERlDUNS*

CUSTOMERlCODE*

CUSTOMERlDUNS*

POINTlOFlRECEIPT*

POINTlOFlDELIVERY*

SERVICElINCREMENT*

TSlCLASS*

TSlTYPE*

TSlPERIOD*

STARTlTIME

STOPlTIME

TIMElOFlLASTlUPDATE

ASSIGNMENTlREF

2. Response

TIMElOFlLASTlUPDATE

SELLERlCODE

SELLERlDUNS

PATHlNAME

POINTlOFlRECEIPT

POINTlOFlDELIVERY

CUSTOMERlCODE

CUSTOMERlDUNS

AFFILIATElFLAG

STARTlTIME (start time of schedule)

STOPlTIME (stop time of schedule)

CAPACITY (reserved)

CAPACITYlSCHEDULED (total of energy scheduled for this customer for this reservation for this hour)

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlWINDOW

TSlSUBCLASS

NERClCURTAILMENTlPRIORITY

OTHERlCURTAILMENTlPRIORITY

ASSIGNMENTlREF (Last rights holder)

4.3.4.2 Curtailment/Interruption (curtail)

Curtailment/Interruption (curtail) provides additional information about the actual curtailment of transmission reservations that have been scheduled for energy exchange. All fields are derived from the reservation except the CAPACITYlCURTAILMENT, CURTAILMENTlREASON and CURTAILMENTlOPTIONS. These fields provide information on

the reasons for the curtailment, procedures to be followed and options for the Customer, if any, to relieve the curtailment.

Template: curtail

1. Query

PATHlNAME

SELLERlCODE*

SELLERlCODE

CUSTOMERlCODE*

CUSTOMERlDUNS*

POINTlOFlRECEIPT*

POINTlOFlDELIVERY*
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38919

SERVICElINCREMENT*

TSlCLASS*

TSlTYPE*

TSlPERIOD*

STARTlTIME

STOPlTIME

TIMElOFlLASTlUPDATE

ASSIGNMENTlREF

2. Response

TIMElOFlLASTlUPDATE

SELLERlCODE

SELLERlDUNS

PATHlNAME

POINTlOFlRECEIPT

POINTlOFlDELIVERY

CUSTOMERlCODE

CUSTOMERlDUNS

AFFILIATElFLAGlSTARTlTIME (Start time of curtailment)

STOPlTIME (Start time of curtailment)

CAPACITY (Capacity reserved)

CAPACITYlSCHEDULED

CAPACITYlCURTAILED

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlWINDOW

TSlSUBCLASS

HERClCURTAILMENTlPRIORITY

OTHERlCURTAILMENTlPRIORITY

CURTAILMENTlREASON

CURTAILMENTlPROCEDURES

CURTAILMENTlOPTIONS

ASSIGNMENTlREF

4.3.5 Query/Response of Lists of Information

4.3.5.1 List (list)

List (list) is used to provide lists of valid names. The minimum set of lists is LIST, SELLERlCODEs, PATHs,

PORs, PODs, SERVICElINCREMENTs, TSlCLASSes, TSlTYPEs, TSlPERIODs, NERClCURTAILMENTlPRIORITY,

OTHERlCURTAILMENTlPRIORITY, ANCILLARYlSERVICElTYPEs, CATEGORYs, and TEMPLATEs. These names may

be used to query information, post or request services.

Template: list

1. Query

LISTlNAME

TIMElOFlLASTlUPDATE

2. Response

TIMElOFlLASTlUPDATE

LISTlNAME

LISTlITEM

LISTlITEMlDESCRIPTION

4.3.6 Query/Response to Obtain the Audit Log

4.3.6.1 Audit Log Information (auditlog)

Audit Log Information (auditlog) is used to provide a means of accessing the required audit information. The TSIP

will maintain two types of logs:

a. Log of all changes to posted TS Information, such as CAPACITY. This log will record as a minimum the time

of the change, the Template name, the name of the Template data element changed and the old and new values

of the Template data element.

b. A complete record of all transaction events, such as those contained in the Templates 4.3.8, 4.3.9 and 4.3.10.

For transaction event logs, the response will include: TIMElSTAMP, TEMPLATE, ELEMENTlNAME, AND NEWlDATA.

In this case the value of OLDlDATA in not applicable.

Template: auditlog

1. Query

STARTlTIME (search against audit log)
38920 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

STOPlTIME (search against audit log)

2. Response

ASSIGNMENTlREF or POSTINGlREF

TIMElSTAMP

TEMPLATE

ELEMENTlNAME (for data elements whose values have changed)

OLDlDATA

NEWlDATA

4.3.7 Purchase Transmission Services

The following Templates shall be used by Customers and Sellers to transact purchases of services.

4.3.7.1 Customer Capacity Purchase Request (transrequest)

The Customer Capacity Purchase Request (Input) (transrequest) is used by the Customer to request the purchase

of transmission services. The response simply acknowledges that the Customer’s request was received by the OASIS

Node. It does not imply that the Seller has received the request. Inputting values into the reference Data Elements

is optional.

CUSTOMERlCODE and CUSTOMERlDUNS shall be determined from the registered connection used to input the

request.

Supporting ‘‘profiles’’ of services, which request different capacities for different time periods within a single request,

is at the discretion of the Primary Provider. Continuation records may be used to indicate requests for these service

profiles. Only the following fields may be redefined in a continuation record for the transrequest Template: CAPACITY,

BIDlPRICE, STARTlTIME, and STOPlTIME.

For requesting transmission services which include multiple paths, only the following fields may be redefined in

a continuation record for the transrequest Template: PATHlNAME. Supporting multiple paths is at the discretion of

the Provider.

The STARTlTIME and STOPlTIME indicate the requested period of service.

When the request is received at the OASIS Node, the TSIP assigns a unique ASSIGNMENTlREF value and queues

the request with a time stamp. The STATUS for the request is QUEUED.

Specification of a value YES in the PRECONFIRMED field authorizes the TSIP to automatically change the STATUS

field in the transstatus Template to CONFIRMED when that request is ACCEPTED by the Seller.

Template: transrequest

1. Input

CONTINUATIONlFLAG

SELLERlCODE (Primary or Reseller)

SELLERlDUNS

PATHlNAME

POINTlOFlRECEIPT

POINTllOFlDELIVERY

SOURCE

SINK

CAPACITY

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlSUBCLASS

STATUSlNOTIFICATION

STARTlTIME

STOPlTIME

BIDlPRICE

PRECONFIRMED

ANClSVClLINK

POSTINGlREF (Optionally set by Customer)

SALElREF (Optionally set by Customer)

REQUESTlREF (Optionally set by Customer)

DEALlREF (Optionally set by Customer)

CUSTOMERlCOMMENTS

2. Response (acknowledgement)

RECORDlSTATUS

CONTINUATIONlFLAG

ASSIGNMENTlREF (assigned by TSIP)

SELLERlCODE

SELLERlDUNS

PATHlNAME
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38921

POINTlOFlRECEIPT

POINTlOFlDELIVERY

SOURCE

SINK

CAPACITY

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlSUBCLASS

STATUSlNOTIFICATION

STARTlTIME

STOPlTIME

BIDlPRICE

PRECONFIRMED

ANClSVClLINK

POSTINGlREF

SALElREF

REQUESTlREF

DEALlREF

CUSTOMERlCOMMENTS

ERRORlMESSAGE

4.3.7.2 Status of Customer Purchase Request (transstatus)

The Status of Customer Purchase Request (transstatus) is provided upon the request of any Customer or Provider

to indicate the current status of one or more reservation records. Users may also view any transaction’s status. Transmission

Providers shall make source and sink information available at the time the request status posting is updated to show

that a transmission request is confirmed.

Only the following fields may be redefined in a continuation record for the transstatus response Template:

PATHlNAME, CAPACITY, STARTlTIME, STOPlTIME, REASSIGNEDlREF, REASSIGNEDlCAPACITY, REASSIGNEDlSTARTlTIME, AND REASSIGNEDlSTOPlTIME.

The AFFILIATElFLAG will be set by the TSIP to indicate whether or not the Customer is an affiliate of the

Primary Provider. The NEGOTIATEDlPRICElFLAG will be set by the TSIP to indicate whether the OFFERlPRICE

is higher, lower, or the same as the BIDlPRICE.

Template: transstatus

1. Query

SELLERlCODE*

SELLERlDUNS*

SELLERlCODE*

CUSTOMERlDUNS*

PATHlNAME*

POINTlOFlRECEIPT*

POINTlOFlDELIVERY*

SERVICElINCREMENT*

TSlCLASS*

TSlTYPE*

TSlPERIOD*

STATUS*

STARTlTIME (Beginning time of service)

STOPlTIME

STARTlTIMElQUEUED (Beginning time queue)

STOPlTIMElQUEUED

NEGOTIATEDlPRICElFLAG

ASSIGNMENTlREF

REASSIGNEDlREF

SALElREF

REQUESTlREF

DEALlREF

TIMElOFlLASTlUPDATE

2. Response

CONTINUATIONlFLAG

ASSIGNMENTlREF

SELLERlCODE

SELLERlDUNS

CUSTOMERlCODE

CUSTOMERlDUNS
38922 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

AFFILIATElFLAG (Set by TSIP)

PATHlNAME

POINTlOFlRECEIPT

POINTlOFlDELIVERY

SOURCE

SINK

CAPACITY (total reservation)

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlWINDOW

TSlSUBCLASS

NERClCURTAILMENTlPRIORITY

OTHERlCURTAILMENTlPRIORITY

STARTlTIME

STOPlTIME

CEILINGlPRICE

OFFERlPRICE

BIDlPRICE

PRECONFIRMED

ANClSVClLINK

ANClSVClREQ

ALTERNATElSERVICElFLAG

POSTINGlREF

SALElREF

REQUESTlREF

DEALlREF

NEGOTIATEDlPRICElFLAG (‘‘L’’ if Seller accepted Price is lower than OFFERlPRICE in transoffering Template; ‘‘H’’

if higher; otherwise blank)

STATUS=RECEIVED, QUEUED, STUDY, REBID, OFFER, ACCEPTED, REFUSED, CONFIRMED, WITHDRAWN, DISPLACED,

ANNULLED, RETRACTED

STATUSlNOTIFICATION

STATUSlCOMMENTS

TIMElQUEUED

RESPONSElTIMElLIMIT

TIMElOFlLASTlUPDATE

PRIMARYlPROVIDERlCOMMENTS

SELLERlCOMMENTS

CUSTOMERlCOMMENTS

SELLERlNAME

SELLERlPHONE

SELLERlFAX

SELLERlEMAIL

CUSTOMERlNAME

CUSTOMERlPHONE

CUSTOMERlFAX

CUSTOMERlEMAIL

REASSIGNEDlCAPACITY (Capacity from each previous transaction)

REASSIGNEDlSTARTlTIME

REASSIGNEDlSTOPlTIME

4.3.8.3 Seller Approval of Purchase (transsell)

Seller Approval of Purchase (Input) (transsell) is input by a Seller to modify the status and queue of a request

by a Customer.

If preconfirmed then Seller can only change values of data elements, STATUS, STATUSlCOMMENTS, SELLERlCOMMENTS, REASSIGNEDlREF, NEGOTIATEDlPRICElFLAG, ANClSRVlREQ, REASSIGNEDlSTARTlTIME,

REASSIGNEDlSTOPlTIME, and REASSIGNEDlCAPACITY. If not preconfirmed, then the Seller can also change

OFFERlPRICE.

Only the following fields may be redefined in a continuation record for the transsell Template: REASSIGNEDlCAPACITY, OFFERlPRICE, REASSIGNEDlREF, REASSIGNEDlSTARTlTIME, and REASSIGNEDlSTOPlTIME.

SELLERlCODE and SELLERlDUNS shall be determined from the registered connection used to input the request.

The Seller may accept a reservation only when the BIDlPRICE and the OFFERlPRICE are the same.

Template: transsell

1. Input

CONTINUATIONlFLAG
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38923

ASSIGNMENTlREF (Required)

OFFERlPRICE

STATUS= RECEIVED, STUDY, OFFER, ACCEPTED, REFUSED, ANNULLED, RETRACTED, DISPLACED

STATUSlCOMMENTS

OTHERlCURTAILMENTlPRIORITY (optional)

ANClSVClREQ

NEGOTIATEDlPRICElFLAG

SELLERlCOMMENTS

RESPONSElTIMElLIMIT

REASSIGNEDlREF

REASSIGNEDlCAPACITY (Previous capacity to be reassigned)

REASSIGNEDlSTARTlTIME

REASSIGNEDlSTOPlTIME

2. Response

RECORDlSTATUS

CONTINUATIONlFLAG

ASSIGNMENTlREF

OFFERlPRICE

STATUS= RECEIVED, STUDY, OFFER, ACCEPTED, REFUSED, ANNULLED, RETRACTED, DISPLACED

STATUSlCOMMENTS

OTHERlCURTAILMENTlPRIORITY

ANClSVClREQ

NEGOTIATEDlPRICElFLAG

SELLERlCOMMENTS

RESPONSElTIMElLIMIT

REASSIGNEDlREF

REASSIGNEDlCAPACITY (Previous capacity to be reassigned)

REASSIGNEDlSTARTlTIME

REASSIGNEDlSTOPlTIME

ERRORlMESSAGE

4.3.7.4 Customer Confirmation of Purchase (Input) (transcust)

Customer Confirmation of Purchase (Input) (transcust) is input by the Customer to state his agreement or withdrawal

of a purchase after the Seller has indicated that the purchase request is approved. Only the BIDlPRICE, STATUS,

STATUSlCOMMENTS, ANClSVClLINK, and CUSTOMERlCOMMENTS data elements can be modified in this Template.

CUSTOMERlCODE and CUSTOMERlDUNS shall be determined from the registered connection used to input the

request.

The Customer must change the BIDlPRICE to be equal to the OFFERlPRICE for each record before the STATUS

can be set to CONFIRMED.

Template: transcust

1. Input

CONTINUATIONlFLAG

ASSIGNMENTlREF (Required)

REQUESTlREF

DEALlREF

BIDlPRICE

STATUS= REBID, CONFIRMED, WITHDRAWN

STATUSlCOMMENTS

ANClSVClLINK

STATUSlNOTIFICATION If left blank, then original URL from the transrequest will be used

CUSTOMERlCOMMENTS

2. Response

RECORDlSTATUS

CONTINUATIONlFLAG

ASSIGNMENTlREF

REQUESTlREF

DEALlREF

BIDlPRICE

STATUS= REBID, CONFIRMED, WITHDRAWN

STATUSlCOMMENTS

ANClSVClLINK

STATUSlNOTIFICATION

CUSTOMERlCOMMENTS

ERRORlMESSAGE
38924 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

4.3.7.5 Alternate Point of Receipt/Delivery (transalt)

Alternate Point of Delivery (transalt). The Customer may submit a request to use alternate points of receipt/delivery

for an existing confirmed reservation, if allowed by applicable tariffs and service agreements. The assignment reference

value associated with the prior confirmed reservation must be provided in the REASSIGNEDlREF data element along

with the alternate points of receipt/delivery. The request may be submitted as PRECONFIRMED. Requests submitted

by the transalt template shall be handled by OASIS identically to reservations submitted using the transrequest template.

CUSTOMERlCODE and CUSTOMERlDUNS shall be determined from the registered connection used to input the

request.

REASSIGNEDlREF contains the ASSIGNMENTlREF of the original, confirmed reservation that is being designated

to the alternate points of delivery/receipt. The Template allows for only one REASSIGNEDlREF Field. Therefore, if

multiple, original reservations are being designated, a separate transalt Template must be submitted associated with

each original reservation. There is no restriction that multiple submissions of the transalt Template may all refer back

to the same, original reservation (i.e., may have the same REASSIGNEDlREF).

Demand profiles associated with the designation of alternate POD/POR may be submitted by additional records

designating ‘‘Y’’ for CONTINUATIONlFLAG, and specifying the CAPACITY, STARTlTIME, and STOPlTIME data

elements corresponding to the MW demand being requested over each time interval associated with the reservation.

The CAPACITY, STARTlTIME, and STOPlTIME data elements must fall within the amounts and time intervals associated with the original reservation.

The following data elements in transstatus and the appropriate ones in transcust shall take on the following implied

values:

SELLERlCODE (value from SELLERlCODE in reservation designated by REASSIGNEDlREF)

SELLERlDUNS (value from SELLERlDUNS in reservation designated by REASSIGNEDlREF)

ALTERNATElSERVICElFLAG = YES

OFFERlPRICE = S0

BIDlPRICE = S0

CEILINGlPRICE = S0

TSlCLASS = Non-Firm (or whatever the Provider designates)

REASSIGNEDlCAPACITY = MW capacity submitted in CAPACITY field of Template

REASSIGNEDlSTARTlTIME = time submitted in STARTlTIME field of Template

REASSIGNEDlSTOPlTIME = time submitted in STOPlTIME field of Template

Template: transalt

1. Input

CONTINUATIONlFLAG

PATHlNAME

POINTlOFlRECEIPT

POINTlOFlDELIVERY

SOURCE

SINK

PRECONFIRMED

CAPACITY (Must be less than or equal to original capacity reservation)

STATUSlNOTIFICATION

STARTlTIME (Valid only to hour and within the time of original reservation)

STOPlTIME (Valid only to hour and within the time of original reservation)

REQUESTlREF

DEALlREF

REASSIGNEDlREF (Assignment Reference for the Firm reservation being used for request)

CUSTOMERlCOMMENTS

2. Response (acknowledgment)

RECORDlSTATUS

CONTINUATIONlFLAG

ASSIGNMENTlREF (assigned by the TSIP)

SELLERlCODE (Primary)

SELLERlDUNS

PATHlNAME

POINTlOFlRECEIPT

POINTlOFlDELIVERY

SOURCE

SINK

PRECONFIRMED

ALTERNATElSERVICElFLAG (Defaulted to YES)

CAPACITY (Capacity requested)

STATUSlNOTIFICATION

STARTlTIME

STOPlTIME

REQUESTlREF
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38925

DEALlREF

REASSIGNEDlREF (Assignment Reference for the Firm reservation being used for request)

ERRORlMESSAGE

4.3.7.6 Seller to Reassign Service Rights to Another Customer (transassign)

Seller to Reassign Service Rights to Another Customer (Input) (transassign) is used by the seller to ask the Transmission

Services Information Provider to reassign some or all of the seller’s rights to Services to another Customer, for seller

confirmed transactions that have occurred off the OASIS. The TSIP shall assign a unique ASSIGNMENTlREF in the

response (acknowledgment) and enter the status CONFIRMED as viewed in the transstatus Template.

SELLERlCODE and SELLERlDUNS shall be determined from the registered connection used to input the request.

Only the following fields may be redefined in a continuation record for the transassign input Template: CAPACITY,

STARTlTIME, STOPlTIME, REASSIGNEDlREF, REASSIGNEDlCAPACITY, REASSIGNEDlSTARTlTIME, and REASSIGNEDlSTOPlTIME.

SELLERlCODE and SELLERlDUNS shall be determined from the registered connection used to input the request.

Template: transassign

1. Input

CONTINUATIONlFLAG

CUSTOMERlCODE

CUSTOMERlDUNS

PATHlNAME

POINTlOFlRECEIPT

POINTlOFlDELIVERY

SOURCE

SINK

CAPACITY

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlSUBCLASS

STARTlTIME

STOPlTIME

OFFERlPRICE

ANClSVClLINK (optional: filled in if assignment is different than original transmission reservation)

POSTINGlNAMES

REASSIGNEDlREF

REASSIGNEDlCAPACITY (Capacity being sold from each previous assignment)

REASSIGNEDlSTARTlTIME

REASSIGNEDlSTOPlTIME

SELLERSlCOMMENTS

2. Response (acknowledgement)

RECORDlSTATUS

CONTINUATIONlFLAG

ASSIGNMENTlREF (assigned by TSIP)

CUSTOMERlCODE

CUSTOMERlDUNS

PATHlNAME

POINTlOFlRECEIPT

POINTlOFlDELIVERY

SOURCE

SINK

CAPACITY (Total capacity being reassigned)

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlSUBCLASS

STARTlTIME

STOPlTIME

OFFERlPRICE

ANClSVClLINK

POSTINGlNAME

REASSIGNEDlREF

REASSIGNEDlCAPACITY (Capacity being sold from each previous assignment)

REASSIGNEDlSTARTlTIME

REASSIGNEDlSTOPlTIME
38926 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

SELLERlCOMMENTS

ERRORlMESSAGE

4.3.8 Seller Posting of Transmission Services

Sellers shall use the following Templates for providing sell information. They may aggregate portions of several

previous purchases to create a new service, if this capability is provided by the Transmission Services Information

Provider:

4.3.8.1 Seller Capacity Posting (transpost)

Seller Capacity Posting (Input) (transport shall be used by the Seller to post the transmission capacity for resale

on to the OASIS Node.

SELLERlCODE and SELLERlDUNS shall be determined from the registered connection used to input the request.

Template: transpost

1. Input

PATHlNAME

POINTlOFlRECEIPT

POINTlOFlDELIVERY

INTERFACElTYPE

CAPACITY

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlWINDOW

TSlSUBCLASS

OTHERlCURTAILMENTlPRIORITY (optional)

ANClSVClREQ

STARTlTIME

STOPlTIME

OFFERlSTARTlTIME

OFFERlSTOPlTIME

SALElREF

OFFERlPRICE

SERVICElDESCRIPTION

SELLERlCOMMENTS

2. Response (Acknowledgment)

RECORDlSTATUS

POSTINGlREF (Assigned by TSIP)

PATHlNAME

POINTlOFlRECEIPT

POINTlOFlDELIVERY

INTERFACElTYPE

CAPACITY

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlWINDOW

TSlSUBCLASS

OTHERlCURTAILMENTlPRIORITY

ANClSVClREQ

STARTlTIME

STOPlTIME

OFFERlSTARTlTIME

OFFERlSTOPlTIME

SALElREF

OFFERlPRICE

SERVICElDESCRIPTION

SELLERlCOMMENTS

ERRORlMESSAGE

4.3.8.2 Seller Capacity Modify (transupdate)

Seller Capacity Modify (Input) (transupdate) shall be used by a Seller to modify a posting of transmission capacity.

SELLERlCODE and SELLERlDUNS shall be determined from the registered connection used to input the request.

Template: transupdate

1. Input

POSTINGlREF (Must be provided)
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38927

CAPACITY (only if modified)

STARTlTIME (only if modified)

STOPlTIME (only if modified)

OFFERlSTARTlTIME (only if modified)

OFFERlSTOPlTIME (only if modified)

ANClSVClREQ (only if modified)

SALElREF (only if modified)

OFFERlPRICE (only if modified)

SERVICElDESCRIPTION (only if modified)

SELLERlCOMMENTS (only if modified)

2. Response (acknowledgment)

RECORDlSTATUS

POSTINGlREF

CAPACITY

STARTlTIME

STOPlTIME

OFFERlSTARTlTIME

OFFERlSTOPlTIME

ANClSVClREQ

SALElREF

OFFERlPRICE

SERVICElDESCRIPTION

SELLERlCOMMENTS

ERRORlMESSAGE

4.3.9 Purchase of Ancillary Services

4.3.9.1 Customer Requests to Purchase Ancillary Services (ancrequest)

Customer Requests to Purchase Ancillary Services (ancrequest) (Input, Template Upload) is used by the customer

to purchase ancillary services that have been posted by a seller of those services. The same requirements exist for

the use of STATUSlNOTIFICATION as for transrequest. The reference Data Elements are optional.

CUSTOMERlCODE and CUSTOMERlDUNS shall be determined from the registered connection used to input the

request.

Template: ancrequest

1. Input

SELLERlCODE

SELLERlDUNS

CONTROLlAREA

CAPACITY

SERVCIElINCREMENT

ANClSERVICElTYPE

STATUSlNOTIFICATION

STARTlTIME

STOPlTIME

BIDlPRICE

PRECONFIRMED

POSTINGlREF (Optionally Set by Customer)

SALElREF (Optionally Set by Customer)

REQUESTlREF (Optionally Set by Customer)

DEALlREF (Optionally Set by Customer)

CUSTOMERlCOMMENTS

2. Response (acknowledgment)

RECORDlSTATUS

ASSIGNMENTlREF (assigned by TSIP)

SELLERlCODE

SELLERlDUNS

CONTROLlAREA

CAPACITY

SERVICElINCREMENT

ANClSERVCIElTYPE

STATUSlNOTIFICATION

STARTlTIME

STOPlTIME

BIDlPRICE

PRECONFIRMED
38928 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

POSTINGlREF

SALElREF

REQUESTlREF

DEALlREF

CUSTOMERlCOMMENTS

ERRORlMESSAGE

4.3.9.2 Ancillary Services Status (ancstatus)

Ancillary Services Status (ancstatus) is used to provide the status of purchase requests regarding the ancillary services

that are available for sale by all Service Providers.

The AFFILIATElFLAG will be set by the TSIP to indicate whether or not the Customer is an affiliate of the

Seller.

The values of STATUS and processes for setting STATUS are the same as for transstatus.

Template: ancstatus

1. Query

SELLERlCODE*

SELLERlDUNS*

CUSTOMERlCODE*

CUSTOMERlDUNS*

CONTROLlAREA

SERVICElINCREMENT

ANClSERVICElTYPE

STATUS

STARTlTIME

STOPlTIME

STARTlTIMElQUEUED

STOPlTIMElQUEUED

ASSIGNMENTlREF

SALElREF

REQUESTlREF

DEALlREF

TIMElOFlLASTlUPDATE (only if TIMElOFlLASTlUPDATE is posted by record)

2. Response

ASSIGNMENTlREF

SELLERlCODE

SELLERlDUNS

CUSTOMERlCODE

CUSTOMERlDUNS

AFFILIATElFLAG (Set by TSIP)

CONTROLlAREA

CAPACITY

SERVICElINCREMENT

ANClSERVICElTYPE

STARTlTIME

STOPlTIME

CEILINGlPRICE

OFFERlPRICE

BIDlPRICE

PRECONFIRMED

POSTINGlREF

SALElREF

REQUESTlREF

DEALlREF

NEGOTIATEDlPRICElFLAG (‘‘L’’ if Seller accepted Price is lower than OFFERlPRICE in ancoffering Template; ‘‘H’’

if higher; otherwise blank)

STATUS=QUEUED, RECEIVED, REBID, OFFER, ACCEPTED, REFUSED, CONFIRMED, WITHDRAWN, ANNULLED, RETRACTED

STATUSlNOTIFICATION

STATUSlCOMMENTS

TIMElQUEUED

RESPONSElTIMElLIMIT

TIMElOFlLASTlUPDATE

PRIMARY lPROVIDERlCOMMENTS

SELLERlCOMMENTS

CUSTOMERlCOMMENTS

SELLERlNAME
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38929

SELLERlPHONE

SELLERlFAX

SELLERlEMAIL

CUSTOMERlNAME

CUSTOMERlPHONE

CUSTOMERlFAX

CUSTOMERlEMAIL

4.3.9.3 Seller Approves Ancillary Service (ancsell)

Seller Approves Ancillary Service (ancsell) is used by the Seller to confirm acceptance after the Seller has approved

the purchase an ancillary service.

SELLERlCODE and SELLERlDUNS shall be determined from the registered connection used to input the request.

Template: ancsell

1. Input

ASSIGNMENTlREF (Required)

OFFERlPRICE

STATUS=RECEIVED, OFFER, ACCEPTED, REFUSED

STATUSlCOMMENTS

SELLERlCOMMENTS

2. Response (acknowledgment)

RECORDlSTATUS

ASSIGNMENTlREF

OFFERlPRICE

STATUS=RECEIVED, OFFER, ACCEPTED, REFUSED

STATUSlCOMMENTS

NEGOTIATEDlPRICElFLAG

RESPONSElTIMElLIMIT

SELLERlCOMMENTS

ERRORlMESSAGE

4.3.9.4 Customers accepts Ancillary Service (anccust)

Customers accepts Ancillary Service (anccust) is used by the customer to confirm acceptance after the seller has

approved the purchase of ancillary service.

The Customer must change the BIDlPRICE to be equal to the OFFERlPRICE before the STATUS can be set to

CONFIRMED.

customerlCODE and CUSTOMERlDUNS shall be determined from the registered connection used to input the

request.

Template: anccust

1. Input

ASSIGNMENTlREF (Required)

REQUESTlREF

DEAL—REF

BIDlPRICE

STATUS=REBID, CONFIRMED, WITHDRAWN

STATUSlCOMMENTS

STATUSlNOTIFICATION (If left blank, then the original URL from the ancrequest will be used

CUSTOMERlCOMMENTS

2. Response (Acknowledgment)

RECORDlSTATUS

ASSIGNMENTlREF

REQUESTlREF

DEALlREF

BIDlPRICE

STATUS=REBID, CONFIRMED, WITHDRAWN

STATUSlCOMMENTS

STATUSlNOTIFICATION

CUSTOMERlCOMMENTS

ERRORlMESSAGE

4.3.10 Seller Posting of Ancillary Services

4.3.10.1 Seller Ancillary Services Posting (ancpost)

Seller Ancillary Services Posting (ancpost) is used by the Seller to post information regarding the different services

that are available for sale by third party Sellers of ancillary services.
38930 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

SELLERlCODE and SELLERlDUNS shall be determined from the registered connection used to input the request.

Template: ancpost

1. Input

CONTROLlAREA

SERVICElDESCRIPTION

CAPACITY

SERVICElINCREMENT

ANClSERVICElTYPE

STARTlTIME

STOPlTIME

OFFERlSTARTlTIME

OFFERlSTOPlTIME

SALElREF

OFFERlPRICE

SELLERlCOMMENTS

2. Response (acknowledgement)

RECORDlSTATUS

POSTINGlREF (Assigned by TSIP)

CONTROLlAREA

SERVICElDESCRIPTION

CAPACITY

SERVICElINCREMENT

ANClSERVICElTYPE

STARTlTIME

STOPlTIME

OFFERlSTARTlTIME

OFFERlSTOPlTIME

SALElREF

OFFERlPRICE

SELLERlCOMMENTS

ERRORlMESSAGE

4.3.10.2 Seller Modify Ancillary Services Posting (ancupdate)

Seller Modify Ancillary Services Posting (ancupdate) is used by the Seller to modify posted information regarding

ancillary services that are available for sale by a third party Seller.

SELLERlCODE and SELLERlDUNS shall be determined from the registered connection used to input the request.

Template: ancupdate

1. Input

POSTINGlREF (Required)

CAPACITY (only if modified)

SERVICElDESCRIPTION (only if modified)

STARTlTIME (only if modified)

STOPlTIME (only if modified)

OFFERlSTARTlTIME (only if modified)

OFFERlSTOPlTIME (only if modified)

SALElREF (only if modified)

OFFERlPRICE (only if modified)

SELLERlCOMMENTS (only if modified)

2. Response (acknowledgment)

RECORDlSTATES

POSTINGlREF

CAPACITY

SERVICElDESCRIPTION

STARTlTIME

STOPlTIME

OFFERlSTARTlTIME

OFFERlSTOPlTIME

SALElREF

OFFERlPRICE

SELLERlCOMMENTS

ERRORlMESSAGE

4.3.11 Informal Messages

4.3.11.1 Provider/Customer Want Ads and Informal Message Posting Request (messagepost)

Provider/Customer Want Ads and Informal Message Posting Request (messagepost) is used by Providers and Customers

who wish to post a message. The valid entries for CATEGORY shall be defined by providers and shall be listed

in the List of CATEGORY Template.
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38931

One CATEGORY shall be DISCOUNT. All discount prices accepted by a Customer shall be immediately posted

as a message using the DISCOUNT CATEGORY. This will permit carry-over from Phase 1.

CUSTOMERlCODE and CUSTOMERlDUNS shall be determined from the registered connection used to input the

request.

Template: messagepost

1. Input

SUBJECT

CATEGORY

VALIDlFROMlTIME

VALIDlTOlTIME

MESSAGE (must be specified)

2. Response (acknowledgment)

RECORDlSTATUS

POSTINGlREF (assigned by information provider)

SUBJECT

CATEGORY

VALIDlFROMlTIME

VALIDlTOlTIME

MESSAGE

ERRORlMESSAGE

4.3.11.2 Message (message)

Message (message) is used to view a posted Want Ad or Informal Message. The CATEGORY data element can

be queried. Specifically it shall be possible to query for the CATEGORY of DISCOUNT. This will permit carry-over

from Phase 1.

Template: message

1. Query

CUSTOMERlCODE

CUSTOMERlDUNS

POSTINGlREF

CATEGORY

VALIDlFROMlTIME

VALIDlTOlTIME

TIMElPOSTED

2. Response

CUSTOMERlCODE

POSTINGlREF

SUBJECT

CATEGORY

VALIDlFROMlTIME

VALIDlTOlTIME

TIMElPOSTED

CUSTOMERlNAME

CUSTOMERlPHONE

CUSTOMERlFAX

CUSTOMERlEMAIL

MESSAGE

4.3.11.3 Provider/Sellers Message Delete Request (messagedelete)

Provider/Sellers Message Delete Request (messagedelete) is used by Providers and Sellers who wish to delete their

message. The POSTINGlREF number is used to determine which message.

CUSTOMERlCODE and CUSTOMERlDUNS shall be determined from the registered connection used to input the

request.

Template: messagedelete

1. Input

POSTINGlREF

2. Response (acknowledgment)

RECORDlSTATUS

POSTINGlREF

ERRORlMESSAGE
38932 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

4.3.11.4 Personnel Transfers (personnel)

Template: personnel

1. Query

TIMElOFlLASTlUPDATE

STARTlTIMElPOSTED

STOPlTIMElPOSTED

2. Response

POSTINGlNAME

EMPLOYEElNAME

FORMERlPOSITION

FORMERlCOMPANY

FORMERlDEPARTMENT

NEWlPOSITION

NEWlCOMPANY

NEWlDEPARTMENT

DATElTIMElEFFECTIVE

DATElTIMElPOSTED

TIMElOFlLASTlUPDATE

4.3.11.5 Discretion (discretion)

Template: discretion

1. Query

STARTlTIMElPOSTED

STOPlTIMElPOSTED

STOPlTIME

SERVICElTYPE

SERVICElNAME

TIMElOFlLASTlUPDATE

2. Response

POSTINGlNAME

RESPONSIBLElPARTYlNAME (name of person granting discretion)

SERVICElTYPE (ancillary or transmission)

SERVICElNAME (make consistent with offering Templates)

TARIFFlREFERENCE

STARTlTIME

STOPlTIME

DISCRETIONlDESCRIPTION

TIMElPOSTED

TIMElOFlLASTlUPDATE

4.3.11.6 Standards of Conduct (stdconduct)

Template: stdconduct

1. Query

STARTlTIMElPOSTED

STOPlTIMElPOSTED

TIMElOFlLASTlUPDATE

2. Response

POSTINGlNAME

RESPONSIBLElPARTYlNAME

STANDARDSlOFlCONDUCTlISSUES

TIMElPOSTED

TIMElOFlLASTlUPDATE

4.4 FILE REQUEST AND FILE DOWNLOAD EXAMPLES

4.4.1 File Example for Hourly Offering

Example of the request to Primary Provider, aaa, and response for Seller, wxyz, for PATHlNAME ‘‘W/AAAA/

PATH–ABC//’’ for April 10, 1996 from 8 a.m. to 3 p.m. (Note that the PATHlNAME consists of a REGIONlCODE,

PRIMARYlPROVIDERlCODE, PATHlCODE, and an OPTIONALlCODE, separated with a slash, ‘‘/’’.) The VERSION

for Phase 1A is 1.2.

The request is in the form of a URL query string and the response is a ASCII delimited file.

1. Query

http://(OASIS Node name)/OASIS/aaa/data/transoffering? ver=1.2 &templ=transoffering &fmt=data &pprov=AAAA

&pprovduns=123456789 &path=W/AAA/ABC// &seller=WXYZAA &sellerduns=987654321 &POR=aaa &POD=bbb

&service=hourly &TSCLASS1=firm &TSCLASS2=non-firm &stime=19960410080000PD &sptime=19960410150000PD
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38933

2. Response Data

REQUEST-STATUS=200↵ (Successful)

TIMElSTAMP=19960409113526PD↵

VERSION=1.2↵

TEMPLATE=transoffering↵

OUTPUTlFORMAT=DATA↵

PRIMARYlPROVIDERlCODE=AAAA↵

PRIMARYlPROVIDERlDUNS=123456789↵

DATAlROWS=14↵

COLUMNlHEADERS=TIMElOFlLASTlUPDATE, SELLERlCODE, SELLERlDUNS, PATHlNAME,

POINTlOFlRECEIPT, POINTlOFlDELIVERY, INTERFACElTYPE, OFFERlSTARTlTIME, OFFERlSTOPlTIME,

STARTlTIME, STOPlTIME, CAPACITY, SERVICElINCREMENT, TSlCLASS, TSlTYPE,TSlPERIOD, TSlSUBCLASS,

SALElREF, POSTINGlREF, CEILINGlPRICE, OFFERlPRICE, PRICElUNITS, SERVICElDESCRIPTION, SELLERlNAME, SELLERlPHONE, SELLERlFAX, SELLER-EMAIL, SELLERlCOMMENTS↵

19960409030000PD,WXYZ, 987654321,W/AAA/ABC//,N/A,N/A,E, 19960402080000PD,

19960410080000PD,19960410080000PD,19960410090000PD,300, HOURLY, FIRM, POINTlT0lPOINT, OFFlPEAK, N/

A,N/A,A001,1.50,1.35,MW,N/A,N/A,N/A,N/A,N/A,10% DISCOUNT↵

19960409030000PD,WXYZ,987654321,W/AAA/ABC//,N/A,N/A,E, 19960402080000PD,

19960410080000PD,19960410080000PD,19960410090000PD,300, HOURLY, NON-FIRM, POINTlT0lPOINT. OFFlPEAK,

N/A,N/A,A001,1.50,1.35,MW,N/A,N/A,N/A,N/A,N/A,10% DISCOUNT↵

19960409030000PD,WXYZ,987654321,W/AAA/ABC//,N/A,N/A,E, 19960402080000PD,

19960410080000PD,19960410090000PD,1996041010000PD,300, HOURLY, FIRM, POINTlT0lPOINT, OFFlPEAK, N/A,N/

A,A001,1.50,1.35,MW,N/A,N/A,N/A,N/A,N/A,10% DISCOUNT↵

19960409030000PD,WXYZ,987654321,W/AAA/ABC//,N/A,N/A,E, 19960402080000PD,

19960410080000PD,19960410090000PD,199604100000PD,300, HOURLY, NON-FIRM, POINTlT0lPOINT, OFFlPEAK, N/

A,N/A,A001,1.50,1.35,MW,N/A,N/A,N/A,N/A,N/A,10% DISCOUNT↵

19960409030000PD,WXYZ,987654321,W/AAA/ABC//,N/A,N/A,E, 19960402080000PD,

19960410080000PD,19960410100000PD,19960410110000PD,300 HOURLY, NON-FIRM, POINTlT0lPOINT, OFFlPEAK,

N/A,N/A,A001,1.50,1.35,MW,N/A,N/A,N/A,N/A,N/A,10% DISCOUNT↵

19960409030000PD,WXYZ,987654321,W/AAA/ABC//,N/A,N/A,E, 19960402080000PD,

19960410100000PD,19960410110000PD,19960410110000PD,300, HOURLY, NON-FIRM, POINTlT0lPOINT, OFFlPEAK,

N/A,N/A,A001,1.50,1.35,MW,N/A,N/A,N/A,N/A,N/A,10% DISCOUNT↵

19960409030000PD,WXYZ,987654321,W/AAA/ABC//,N/A,N/A,E, 19960402080000PD,

19960410080000PD,19960410110000PD,19960410120000PD,300, HOURLY, FIRMPOINTlT0lPOINT, OFFlPEAK, N/A,N/

A,A001,1.50,1.35,MW,N/A,N/A,N/A,N/A,N/A,10% DISCOUNT↵

19960409030000PD,WXYZ,987654321,W/AAA/ABC//,N/A,N/A,E, 19960402080000PD,

19960410080000PD,19960410110000PD,19960410120000PD,300, HOURLY, NON-FIRM, POINTlT0lPOINT, OFFlPEAK

,N/A,N/A,A001,1.50,1.35,MW,N/A,N/A,N/A,N/A,N/A,10% DISCOUNT↵

. . .

. . .

. . .

19960409030000PD,WXYZ,987654321,W/AAA/ABC//,N/A,N/A,E, 19960402080000PD,

19960410080000PD,19960410140000PD,19960410150000PD,300, HOURLY, FIRM, POINTlT0lPOINT, OFFlPEAK, N/

A,N/A,A001,1.50,1.35,MW,N/A,N/A,N/A,N/A,N/A,10% DISCOUNT↵

1996040903000PD. WXYZ. 987654321. W/AAA/ABC//, N/A,N/A,E. 19960402080000PD, 19960410080000PD,

19960410140000PD. 19960410150000PD.300. HOURLY, NON-FIRM, POINTl TOl POINT, OFFlPEAK, N/A, N/

A,A001,1.50. 1,35,MW,N/A,N/A,N/A,N/A,N/A,10% DISCOUNT↵

4.4.2 File Example for Hourly Schedule Data

The example shows a request for the hourly schedule data from Primary Provider, aaa, related to the seller, wxyz,

for the period 10 a.m. to 3 p.m. on April 10, 1996.

There are two idential requests examples using two slightly different methods. The first request is using a HTTP

URL request string through an HTML GET method. The second request is a similar example using fetchlhttp from

a file using a POST method.

1. Query

URL Request (HTTP method=GET)

http://OASIS Node name)/OASIS/aaa/data/schedule? ver=1.0 & pprov=AAAA & templ=schedule & fmt=data &

pprovduns=123456789 & path=W/AAA/ABC// & seller=WXYZ & por=BBB & CCC & tz=PD & stime=19960410100000PD

& sptime=19960410150000PD

URL request (HTTP method=POST)

S fetchlhttp http://(OASIS Node name)/OASIS/aaa/data/ OASISDATA-fc:/OASIS/ wxyz/upload/in-file.txt Where in-file.txt

contains the following: ver=1.0 & pprov=AAAA & Templ=schedule & fmt=data & pprovduns=123456789 & path=W/

AAA/ABC// & seller=WXYZ &por=BBB &pod=CCC & tz=PD & stime=19960410100000PD & sptime-19960410150000PD

2. Response Data

REQUEST-STATUS=200↵
38934 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

TIMElSTAMP=19960410114702PD↵

VERSION-1.2↵

TEMPLATE=schedule↵

OUTPUTlFORMAT=DATA↵

PRIMARYlPROVIDERlCODE=AAAA↵

PRIMARYlPROVIDERlDUNS=123456789↵

DATAlROWS=5↵

COLUMNlHEADERS=TIMElOFlLASTlUPDATE, SELLERlCODE. SELLERlDUNS, PATHlNAME,

POINTlOFlRECEIPT. POINTlOFlDELIVERY, CUSTOMERlCODE. CUSTOMERlDUNS, AFFILIATElFLAG,

STARTlTIME. STOPlTIME, CAPACITY, CAPACITYlSCHEDULED, SERVICElINCREMENT, TSlCLASS, TSlTYPE,

TSlPERIOD, TSlSUBCLASS, ASSIGNMENTlREF↵

1996049030000pd.wxyz.0987654321. W/AAA/ABC//.BBB.CCC. WXYZAA.0987654322.Y.19960410100000PD.

19960410110000PD.300.300. HOURLY, FIRM, POINTl TOl POINT, OFFl PEAK, N/A, 856743↵

. . .↵

. . .↵

1996049030000pd.wxyz.0987654321. W/AAA/ABC//.BBB.CCC.WXYZAA. 0987654322.Y. 19960410130000PD.

19960410140000PD.300.300. HOURLY, FIRM, POINTl TOl POINT, OFFl PEAK, N/A, 856743↵

1996049030000pd.wxyz. 0987654321.W/AAA/ABC//.BBB.CCC. WXYZAA.0987654322.Y. 19960410140000PD.

19960410150000PD.300.300. HOURLY, FIRM, POINTl TOl POINT, OFFl PEAK, N/A, 856743↵

4.4.3 Customer Posting a Transmission Service Offering

The example shows how a Customer would post for sale the transmission service that was purchased previously.

The Seller would create a file and upload the file using the FETCHl HTTP program to send a file to the OASIS

node of the Primary Provider.

1. Input:

VERSION-1.2↵

TEMPLATE=transpost↵

OUTPUTl FORMAT=DATA↵

PRIMARYl PROVIDERl CODE=AAAA↵

PRIMARYl PROVIDERl DUNS=123456789↵

DATAl ROWS=1↵

COLUMNlHEADERS=PATHlNAME, POINTlOFlDELIVER, INTERFACElTYPE, CAPACITY, SERVICElINCREMENT,

TSlCLASS, TSlTYPE, TSlPERIOD, TSlSUBCLASS, STARTlTIME, STOPlTIME, OFFERlSTARTl TIME,

OFFERlSTOPl TIME, SALElREF. OFFERlPRICE, SERVICElDESCRIPTION, SELLERlCOMMENTPF↵

WXYZ.987654321.W/AAA/ABC//.N/A,N/A.E.150, HOURLY, FIRM, POINTl TOl POINT, OFFl PEAK, N/A/

.19960402080000PD, 19960410080000PD, 19960410080000PD, 199604101500PD, A123.90.N/A, ‘‘As Joe said, ‘‘‘‘It is a

good buy’’’’’’↵

FETCHl HTTP Command to send posting

S fetchl http http//(OASIS Node name)/OASIS/abcd/data/transrequest-fc:/OASIS/abcd/upload/post.txt

2. Response Data

REQUEST-STATUS=200↵(Successful)

TIMEl STAMP=19960409113526PD↵

VERSION-1.2↵

TEMPLATE=transpost↵

OUTPUTl FORMAT=DATA↵

PRIMARYlPROVIDERl CODE=AAAA↵

PRIMARYl PROVIDERl DUNS=123456789↵

DATAl ROWS=1↵

COLUMNlHEADERS=RECORDlSTATUS, PATHlNAME, POINTlOFlRECEIPT, POINTlOFlDELIVER, INTERFACElTYPE, CAPACITY, SERVICElINCREMENT, TSlCLASS, TSlTYPE, TSlPERIOD, TSlSUBCLASS,

STARTlTIME, STOPlTIME, OFFERlSTARTlTIME, OFFERlSTOPl TIMElTIME, SALElREF, OFFERlPRICE,

SERVICElDESCRIPTION, SELLERlCOMMENTS, ERRORlMESSAGE↵

200.WXYZ.987654321, W/AAA/ABC//,N/A, N/A. E.150, HOURLY, FIRM, POINTlTOlPOINT, OFFlPEAK, N/A.

19960402080000PD, 19960410080000PD, 19960410080000PD, 19960410150000PD, A123,.90, N/A/, ‘‘As Joe said, ‘‘‘‘It is

a good buy’’’’’’, No Error↵

4.4.4 Example of Re-aggregating Purchasing Services using Reassignment

The following examples do not show the complete Template information, but only show those elements of the

Template of interest to the example.

a. Customer #1, ‘‘BestE’’ requests the purchase of 150 MW Firm ATC for 8 a.m. to 5 p.m. for $1.00 from a Primary

Provider (transrequest).

TEMPLATE=‘‘transrequest’’↵

CUSTOMERlCODE=‘‘BestE’’↵

CAPACITY=150↵

TSlCLASS=‘‘FIRM’’↵

STARTlTIME=‘‘1996050708000000PD’’↵
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38935

STOPlTIME=‘‘1996050717000000PD’’↵

BIDlPRICE=‘‘$1.00’’↵

The Information Provider assigns ASSIGNMENTlREF=5000 on acknowledgment.

b. Customer #1 purchases 120 MW ATC Non-firm for 3 p.m. to 9 p.m. for $.90 (transrequest). The Information

Provider assigns the ASSIGNMENTlREF=5001 when the request for purchase is made and is shown in the acknowledgment.

TEMPLATE=‘‘transrequest’’↵

CUSTOMERlCODE=‘‘BestE’’↵

CAPACITY=120↵

TSlCLASS=‘‘NON-FIRM’’↵

STARTlTIME=‘‘1996050715000000PD’’↵

STOPlTIME=‘‘1996050721000000PD’’↵

BIDlPRICE=‘‘$1.05’’↵

c. Customer #1 becomes Seller #1 and post the Transmission service of 100 MW ATC Non-firm capacity from

8 a.m. to 9 p.m. for resale at $.90/MW-hour.

TEMPLATE=‘‘transpost’’↵

SELLERlCODE=‘‘BestE’’↵

CAPACITY=100↵

TSlCLASS=‘‘NON-FIRM’’↵

STARTlTIME=‘‘1996050708000000PD’’↵

STOPlTIME=‘‘1996050721000000PD’’↵

SALElREF=‘‘BEST100’’↵

OFFERlPRICE=.90↵

SELLERlCOMMENTS=‘‘aggregating two previous purchases’’↵

d. Customer #2 then requests purchase of 100 MW Non-firm from Reseller #1 from 8 a.m. to 6 p.m. for $0.90/

MW-hour (transrequest).

TEMPLATE=‘‘transrequest’’↵

CUSTOMERlCODE=‘‘Whlsle’’↵

SELLERlCODE=‘‘BestE’’↵

CAPACITY=100↵

TSlCLASS=‘‘NON-FIRM’’↵

STARTlTIME=‘‘1996050708000000PD’’↵

STOPlTIME=‘‘1996050721000000PD’’↵

SALElREF=‘‘BEST100’’↵

DEALlREF=‘‘WPC100’’↵

BIDlPRICE=.90↵

CUSTOMERlCOMMENTS=‘‘Only need service until 6 p.m.’’↵

The Information Provider provides the ASSIGNMENTlREF=5002 for this transaction.

e. Seller informs the Information Provider of the reassignment of the previous transmission rights when the seller

accepts the customer purchase request (transsell).

TEMPLATE=‘‘transsell’’↵

CUSTOMERlCODE=‘‘Whlsle’’↵

SELLERlCODE=‘‘BestE’’↵

ASSIGNMENTlREF=5002↵

STATUS=‘‘Accepted’’↵

REASSIGNEDlREF1=5000↵

REASSIGNEDlCAPACITY1=100↵

REASSIGNEDlSTARTlTIME1=‘‘199605070800PD’’↵

REASSIGNEDlSTOPlTIME1=‘‘199605071700PD’’↵

REASSIGNEDlREF2=5001↵

REASSIGNEDlCAPACITY2=100↵

REASSIGNEDlSTARTlTIME2=‘‘199605071700PD’’↵

REASSIGNEDlSTOPlTIME2=‘‘199605071800PD’’↵

4.4.5 File Examples of the Use of Continuation Records

a. Basic Continuation Records

The first example of the use of Continuation Records is for the transrequest Template submitted by a Seller for

purchase of a transmission reservation spanning 16 hours from 06:00 to 22:00 with ‘‘ramped’’ demand at beginning

and end of time period. Two additional reservations appear prior to and following the profile to demonstrate the

handling of ASSIGNMENTlREF by the OASIS node.

Only the following fields may be redefined in a continuation record for the transrequest Template: CAPACITY,

STARTlTIME, STOPlTIME. Specification of any values corresponding to COLUMNlHEADERs other than CAPACITY,

STARTlTIME, and STOPlTIME will be ignored, however commas must be included to properly align the CAPACITY,

STARTlTIME and STOPlTIME fields.

Input:

VERSION=1.2↵
38936 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

TEMPLATE=transrequest↵

OUTPUTlFORMAT=DATA↵

PRIMARYlPROVIDERlCODE=AEP↵

PRIMARYlPROVIDERlDUNS=123456789↵

DATAlROWS=7↵

COLUMNlHEADERS=CONTINUATIONlFLAG, SELLERlCODE, SELLERlDUNS, PATHlNAME,

POINTlOFlRECEIPT. POINTlOFlDELIVERY, SOURCE, SINK, CAPACITY, SERVICElINCREMENT, TSlCLASS,

TSlTYPE, TSlPERIOD. TSlSUBCLASS, STATUSlNOTIFICATION, STARTlTIME, STOPlTIME, BIDlPRICE.

PRECONFIRMED, ANClSVClLINK, POSTINGlREF, SALElREF, REQUESTlREF, DEALlREF, CUSTOMERlCOMMENTS↵

N. AEP, 123456789, ABC/XY, CE, MECS...35, DAILY, FIRM, POINTlTOlPOINT, OFFlPEAK, N/A., pub/AEP/incoming,

19970423000000ES, 19970424000000ES, 24.50, Y.SC: (cust:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123);

SP:(custR234);SU:(cust:R345), PO123, S123, R765, D123, Standard daily reservation↵

N. AEP, 123456789, ABC/XY, CE, AMPO....5, HOURLY, NON-FIRM. POINTlTOlPOINT, OFFlPEAK, N/A. pub/AEP/

incoming, 19970423060000ES, 19970423070000ES, 2.50, Y, SC:(cust:SP);RV:(cust:SP);RF(cust:RQ);EI:(cust:R 123);

SP:(custR234); SU:(cust:R345), P0123, S123, R765, D123, First piece of profile spanning 5 records↵

Y........10.......19970423070000ES, 19970423080000ES.........Second piece↵

Y........15.......19970423080000ES, 19970423200000ES.........Third piece↵

Y........10.......19970423200000ES, 19970423210000ES.........Fourth piece↵

Y........5........19970423210000ES, 19970423220000ES.........Fifth piece↵

N. AEP, 123456789, ABC/XY, CE, MECS... 20, HOURLY, FIRM POINTlTOlPOINT, OFFlPEAK, N/A, pub/AEP/incoming,

19970423040000ES, 19970423160000ES, 2.00, Y .SC:(cust:SP);RV:(cust:SP);RF(cust:RQ);EI:(cust:R123); SP:(custR234);

SU:(cust:R345), PO123, S123, R765, D123, Standard hourly reservation after profiled reservation↵

Response:

REQUESTlSTATUS=200↵

TIMElSTAMP=19970422160523ES↵

TEMPLATE=transrequest↵

OUTPUTlFORMAT=DATA↵

PRIMARYlPROVIDERlCODE=AEP↵

PRIMARYlPROVIDERlDUNS=123456789↵

DATAlROWS=7↵

COLUMNlHEADERS=RECORDlSTATUS. CONTINUATIONlFLAG, SELLERlCODE. SELLERlDUNS. PATHlNAME.

POINTlOFlRECEIPT. POINTlOFlDELIVERY. SOURCE, SINK, CAPACITY, SERVICElINCREMENT. TSlCLASS.

TSlTYPE. TSlPERIOD. TSlSUBCLASS. STATUSlNOTIFICATION. STARTlTIME. STOPlTIME. BIDlPRICE.

PRECONFIRMED. ANClSVClLINK. POSTINGlREF. SALElREF. REQUESTlREF. DEALlREF, CUSTOMERlCOMMENTS. ERRORlMESSAGE↵

200. N. AEP. 123456789. ABC/XY. CE, MECS...35, DAILY. FIRM. POINTlTOlPOINT. OFFlPEAK, N/A, pub/AEP/

incoming, 19970423000000ES, 19970424000000ES, 24.50.Y.SC:(cust:SP):RV:(cust:SP):RF(cust:RQ); EI:(cust:R123);

SP:(custR234); SU:(cust:R345), P0123, S123, R765, D123, Standard daily reservation, No error↵

200. N. AEP. 123456789. ABC/XY. CE, AMPO...5, HOURLY. NON-FIRM. POINTlTOlPOINT. OFFlPEAK. N/A/, pub/

AEP/incoming. 19970423060000ES, 19970423070000ES, 2.50. Y.SC:(cust:SP);RV:(cust:SP);RF(cust:RQ);EI:(cust:R123);SP:

(custR234); SU:(cust:R345). PO123, R765, D123. First piece of profile spanning 5 records. No error↵

200. Y.......10.......19970423070000ES, 19970423080000ES.........Second piece. No error↵

200. Y.......15.......19970423080000ES, 19970423200000ES.........Third piece. No error↵

200. Y.......10.......19970423200000ES, 19970423210000ES.........Fourth piece. No error. ↵

200. Y.......5........19970423210000ES, 19970423220000ES.........Fifth piece. No error. ↵

200. N. AEP. 123456789, ABC/XY, CE, MECS...20. HOURLY, FIRM, POINTlTOlPOINT, OFFlPEAK, N/A. pub/AEP/

incoming, 19970423040000ES, 19970423160000ES, 2.00, Y. SC:(cust:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123);

SP:(custR234); SU:(cust:R345). PO123, S123, R765, D123. Standard hourly reservation after profiled reservation. No error↵

b. Submission of Reassignment Information—Case 1:

In the prior example, a reservation request was submitted to ‘‘Rseler’’ for 20 MW of Hourly Non-firm service from

04:00 to 16:00. Assume that Rseler has previously reserved service for the CE–VP path for Daily Firm in amount

of 50 MW on 4/23 under ASSIGNMENTlREF=7019, and Hourly Non-Firm in amount of 10 MW from 08:00 to 20:00

on 4/23 under ASSIGNMENTlREF=7880. Rseler must designate which transmission service rights are to be reassigned

to Cust to satisfy the 20MW from 04:00 to 16:00. This reassignment information is conveyed by Rseler using the

transsell Template when the reservation request is ACCEPTED. At the SELLER’s discretion, rights are assigned from

the Non-firm reservation first (ASSIGNMENTlREF=7880) with the balance taken up by the Firm reservation (ASSIGNMENTlREF=7019).

The only fields allowed in ‘‘continuation’’ records for transsell Template are REASSIGNEDlREF, REASSIGNEDlCAPACITY, REASSIGNEDlSTARTlTIME, and REASSIGNEDlSTOPlTIME. Price may not be negotiated for

each ‘‘segment’’ in a capacity profile.

Input:

VERSION=1.2↵

TEMPLATE=transsell↵

OUTPUTlFORMAT=DATA↵

PRIMARYlPROVIDERlCODE=AEP↵
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38937

PRIMARYlPROVIDERlDUNS=123456789↵

DATAlROW=3↵

COLUMNlHEADERS=RECORDlSTATUS, CONTINUATIONlFLAG, ASSIGNMENTlREF. OFFERlPRICE. STATUS.

STATUSlCOMMENTS. ANClSVClLINK. SELLERlCOMMENTS. REASSIGNEDlREF. REASSIGNEDlCAPACITY. REASSIGNEDlSTARTlTIME. REASSIGNEDlSTOPlTIME N. 8236. 2.00, ACCEPTED. Status comments here.

SC:(cust:SP);RV:(cust:SP);RF(cust:RQ);EI:(cust:R123);SP:(CustR234); SU:(cust:R345). Seller comments here. 7019.20,

19970423040000ES. 19970423080000ES↵

200. Y.......7880. 10. 19970423080000ES. 19970423160000ES↵

200. Y.......7019. 10. 19970423080000ES. 19970423160000ES↵

Response:

VERSION=1.2↵

TEMPLATE=transsell↵

OUTPUTlFORMAT=DATA↵

PRIMARYlPROVIDERlCODE=AEP↵

PRIMARYlPROVIDERlDUNS=123456789↵

DATAlROW=3↵

COLUMNlHEADERS=RECORDlSTATUS. CONTINUATIONlFLAG, ASSIGNMENTlREF. OFFERlPRICE. STATUS.

STATUSlCOMMENTS. ANClSVClLINK. SELLERlCOMMENTS. REASSIGNEDlREF. REASSIGNEDlCAPACITY. REASSIGNEDlSTARTlTIME. REASSIGNEDlSTOPlTIME, ERRORlMESSAGES 200. N. 8236.2.00, ACCEPTED. Status

comments here. SC:(cust:SP);RV:(cust:SP);RF(cust:RQ);EI:(cust:R123);sp:(CustR234); SU:(cust:R345). Seller comments here.

7019.20, 19970423040000ES. 19970423080000ES↵

200. Y.......7880. 10. 19970423080000ES. 19970423160000ES↵

200. Y.......7019. 10. 19970423080000ES. 19970423160000ES↵

c. Submission of Reassignment Information—Case 2:

Primary provider, AEP, is notified of a sale/assignment of transmission service rights from ‘‘Resell’’ to ‘‘cust’’. The

parameters of the new reservation are for 10MW or 4/23 for ‘‘off-peak’’ hours (00:00–06:00 and 22:00–24:00) on POR/

POD CE–VP. Rseler is assigning rights to 10MW from a prior reservation for the CE–VP path for Daily Firm in amount

of 50 MW on 4/23 under ASSIGNMENTlREF=7019 to Cust. AEP would submit the following information using the

transassign Template to post this (re)sale. The only fields allowed in ‘‘continuation’’ records for the transassign Template

are CAPACITY, STARTlTIME, STOPlTIME, REASSIGNEDlREF, REASSIGNEDlCAPACITY, REASSIGNEDlSTARTlTIME, and REASSIGNEDlSTOPlTIME.

Even though there is a one-to-one correspondence between the segments of the new reservations and the reassignment

of service from a prior reservation, it is entirely possible that a reservation spanning a single continguous period would

require multiple continuation records to convey reassignment information, and vice versa.

Fields for CUSTOMERlNAME and SELLERlNAME were used to convey user names for subsequent resolution

of contact information from user registration.

Input:

VERSION=1.2↵

TEMPLATE=transassign↵

OUTPUTlFORMAT=DATA↵

PRIMARYlPROVIDERlCODE=AEP↵

PRIMARYlPROVIDERlDUNS=123456789↵

DATAlROWS=2↵

COLUMNlHEADERS=CONTINUATIONlFLAG, CUSTOMERlCODE, CUSTOMERlDUNS, PATHlNAME,

POINTlOFlRECEIPT, POINTlOFlDELIVERY, SOURCE, SINK, CAPACITY, SERVICElINCREMENT, TSlCLASS,

TSlTYPE, TSlPERIOD, TSlSUBCLASS, STARTlTIME, STOPlTIME, OFFERlPRICE, SALElREF, POSTINGlNAME,

REASSIGNEDlREF, REASSIGNEDlCAPACITY, REASSIGNEDlSTARTlTIME, REASSIGNEDlSTOPlTIME, SELLERlCOMMENTS↵

N. Resler, 456123789, Cust. 987654321..CE. VP...10. HOURLY. NON-FIRM, POINTlTOlPOINT, OFFlPEAK, N/A.

19970423000000ES. 19970423060000ES. 2.00, Joe Smith, Jane Doe . N. 19970422121354ES..7019. 10. 19970423000000ES.

19970423060000ES. Seller comments go here↵

Y...........10......19970423220000ES. 19970424000000ES.......7019. 10. 19970423220000ES. 19970424000000ES↵

Response:

REQUESTlSTATUS=200↵

TIMElSTAMP=19970422144520ES↵

VERSION=1.2↵

TEMPLATE=transassign↵

OUTPUTlFORMAT=DATA↵

PRIMARYlPROVIDERlCODE=AEP↵

PRIMARYlPROVIDERlDUNS=123456789↵

DATAlROWS=2↵

COLUMNlHEADERS=RECORDlSTATUS, CONTINUATIONlFLAG, ASSIGNMENTlREF, SELLERlCODE, SELLERlDUNS, CUSTOMERlCODE, CUSTOMERlDUNS, AFFILIATElFLAG, PATHlNAME, POINTlOFlRECEIPT,

POINTlOFlDELIVERY, SOURCE, SINK, CAPACITY, SERVICElINCREMENT, TSlCLASS, TSlTYPE, TSlPERIOD,

TSlSUBCLASS, STARTlTIME, STOPlTIME, OFFERlPRICE, SELLERlNAME, CUSTOMERlNAME, TIMElQUEUED,
38938 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

SALElREF, REASSIGNEDlREF, REASSIGNEDlCAPACITY, REASSIGNEDlSTARTlTIME, REASSIGNEDlSTOPlTIME, SELLERlCOMMENTS, ERRORlMESSAGE↵

200. N. 8207, Rseler, 456123789, Cust. 987654321, N., CE. VP...10, HOURLY, FIRM, POINTlTOlPOINT, OFFlPEAK,

N/A. 19970423000000ES. 19970423060000ES. 2.00, Joe Smith, Jane Doe , 19970422121354ES, . 7019, 10,

19970423000000ES, 19970423060000ES, Seller comments go here.↵

200, Y............10......19970423220000ES, 19970424000000ES......7019, 10, 19970423220000ES, 19970424000000ES..↵

d. Query of Transmission Reservation Status:

The following typical response to a transstatus query might be delivered for 4/23 based on prior examples. Note

that the only fields returned in ‘‘continuation’’ records are, CAPACITY, STARTlTIME, STOPlTIME, REASSIGNEDlREF,

REASSIGNEDlCAPACITY, REASSIGNEDlSTARTlTIME, and REASSIGNEDlSTOPlTIME (price fields are debatable).

Input:

<appropriate query name/value pairs to return reservations for 4/23>

Response:

REQUESTlSTATUS=200↵

TIMElSTAMP=19970423040523ES↵

TEMPLATE=transstatus↵

OUTPUTlFORMAT=DATA↵

PRIMARYlPROVIDERlCODE=AEP↵

PRIMARYlPROVIDERlDUNS=123456789↵

DATAlROWS=11↵

COLUMNlHEADERS= CONTINUATIONlFLAG, ASSIGNMENTlREF, SELLERlCODE, SELLERlDUNS, CUSTOMERlCODE, CUSTOMERlDUNS, AFFILIATElFLAG, PATHlNAME, POINTlOFlRECEIPT,

POINTlOFlDELIVERY, SOURCE, SINK, CAPACITY, SERVICElINCREMENT, TSlCLASS, TSlTYPE, TSlPERIOD,

TSlSUBCLASS, STARTlTIME, STOPlTIME, CEILINGlPRICE, OFFERlPRICE, BIDlPRICE, PRECONFIRMED,

ANClSVClLINK, ALTERNATElSERVICElFLAG, POSTINGlREF, SALElREF, REQUESTlREF, DEALlREF, NEGOTIATEDlPRICElFLAG, STATUS, STATUSlCOMMENTS, TIMElQUEUED, TIMElOFlLASTlUPDATE, PRIMARYlPROVIDERlCOMMENTS, SELLERlCOMMENTS, CUSTOMERlCOMMENTS, SELLERlNAME, SELLERlPHONE, SELLERlFAX, SELLERlEMAIL, CUSTOMERlNAME, CUSTOMERlPHONE, CUSTOMERlFAX, CUSTOMERlEMAIL, REASSIGNEDlREF, REASSIGNEDlCAPACITY, REASSIGNEDlSTARTlTIME, REASSIGNEDlSTOPlTIMES

N. 8207, Rseler, 456123789. ACust. 987654321. N..CE. VP...10, HOURLY, FIRM, POINTlTOlPOINT, OFFlPEAK, N/

A. 19970423000000ES, 19970423060000ES, 2.25, 2.00, 6.20. N.SC:(cust:SP):RV:(cust:SP):RF(cust:RQ); EI:(cust:R123);

SP:(custR234); SU:(cust:R345).N.....N, CONFIRMED..19970422121354ES..TP Comments, Seller comments go here, Customer

comments, Joe Smith, (888)–123–4567, (888)–123–1231, jsmith@xyz.com. Jane Doe, (999)–123–4567, (999)–123–8823..7019,

10, 19970423000000ES. 19970423060000ES↵

Y,,,,,,,,,,,,,10,,,,,,19970423220000ES, 19970424000000ES..............7019, 10, 19970423220000ES, 19970424000000ES↵

N. 8234, Rseler, 456123789. ACust. 987654321.N.CE.MECS...35 DAILY, FIRM, POINTlTOlPOINT, OFFlPEAK, N/A.

19970423000000ES, 19970423060000ES, 42.00, 24.50, 24.50, N,SC:(cust:SP):RV(cust:SP);RF(cust:RQ); E1:(cust:R123);

SP:(custR234); SU:(cust:R345),N.....N, CONFIRMED..19970422121354ES..Standard daily reservation, System Operator, Customer comments, Frank Orth, (999)–123–4567,(999)–123–1231,jsmith@xyx.com, Jane Doe, (999)–123–4567, (999)–123–

8823..7019, 10, 19970423000000ES, 19970423060000ES↵

N. 8235, AEP, 123456789, Cust. 987654321, N.. CE, AMPO...5, HOURLY, NON-FIRM, POINTlTOlPOINT, OFFlPEAK,

N/A/ 19970423060000ES, 19970423070000ES, 2.50, 2.50, 6.20, N, SC:(cust:SP):RV(cust:SP);RF(cust:RQ); E1:(cust:R123);

SP:(custR234); SU:(cust:R345),N.....N,CONFIRMED..19970422160523ES..Profile verified. First piece. Customer comments,

System Operator, (888)–123–4567, (888)–123–1231, jsmith@xyz.com.Jane Doe (999)–123–4567, (999)–123–8823..7019, 10,

19970423000000ES, 19970423060000ES↵

Y............10.......19970423070000ES, 19970423080000ES.........................↵

Y............15.......19970423080000ES, 19970423200000ES.........................↵

Y............10.......19970423200000ES, 19970423210000ES.........................↵

Y............5........19970423210000ES, 19970423220000ES.........................↵

N, 8236, Rseler, 456123789, Cust, 987654321, N..CE, VP...20,HOURLY, FIRM, POINTlTOlPOINT, OFFlPEAK, N/A,

19970424040000ES, 19970424160000ES, 2.00, 2.50, 6.20, N.....CONFIRMED,, 19970422160523ES..Bid price refused, Negotiated OFFERlPRICE accepted, Joe Smith, (888)–123–4567, (888)–123–1231, jsmith@xyz.com, Jane Doe, (999)–123–4567,

(999)–123–8823..7019, 20, 19970423040000ES, 199704230080000ES↵

Y......................................7880.10.......19970423080000ES, 19970423160000ES↵

Y......................................7019.10......19970423080000ES, 19970423160000ES↵

4.4.6 Example of Negotiation of Price

4.4.6.1 Negotiation with Preconfirmation

a. The Customer submits a PRECONFIRMED transmission service request using the transrequest Template. Initially,

the STATUS is set to QUEUED by OASIS.

b. The Seller has the option of setting STATUS via the transsell Template to one of the following: RECEIVED,

STUDY, ACCEPTED, or REFUSED. Since the request is PRECONFIRMED, the Seller is blocked from altering OFFERlPRICE

by OASIS, and blocked from setting status to OFFER.

c. If the Seller sets STATUS to ACCEPTED, OASIS will immediately set STATUS to CONFIRMED and sets the

OFFERlPRICE to the BIDlPRICE.
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38939

d. The Customer may WITHDRAW request via transcust Template at any time up to point where the Seller sets

STATUS to ACCEPTED.

e. Once the STATUS is CONFIRMED, the OFFERlPRICE officially becomes the terms of the reservation.

4.4.6.2 Negotiations without Preconfirmation

a. The Customer submits a transmission reservation request with the BIDlPRICE less than the CEILINGlPRICE

via the transrequest Template. Initially the STATUS is set to QUEUED by OASIS.

b. The Seller has the option of setting the STATUS via the transsell Template to one of the following: RECEIVED,

STUDY, ACCEPTED, OFFER, or REFUSED.

c. The Seller determines that the BIDlPRICE is too low, sets the OFFERlPRICE to the price he wants, and sets

the STATUS to OFFER via the transsell Template.

d. The Customer agrees to the OFFERlPRICE, sets the BIDlPRICE equal to the OFFER PRICE, and sets the STATUS

to CONFIRMED via the transcust Template.

e. The OFFERlPRICE with the STATUS of CONFIRMED locks in the terms of the reservation.

4.4.6.3 Multiple Step Negotiations

a. The Customer submits a transmission reservation request with the BIDlPRICE less than the CEILINGlPRICE

via the transrequest Template. Initially the STATUS is set to QUEUED by OASIS.

b. The Seller has the option of setting STATUS via the transsell Template to one of the following: RECEIVED,

STUDY, ACCEPTED, OFFER, or REFUSED.

c. The Seller determines that the BIDlPRICE is too low, sets the OFFERlPRICE to the desired value, and sets

the STATUS to OFFER via the transsell Template.

d. The Customer responds to the new OFFERlPRICE with an updated BIDlPRICE and sets the STATUS to REBID

for re-evaluation by the Seller.

e. The Seller determines that the BIDlPRICE now is acceptable and sets the STATUS to ACCEPTED via the transsell

Template. The transition to ACCEPTED state requires the OFFERlPRICE to be set to the BIDlPRICE: accepting a

reservation with an OFFERlPRICE different from BIDlPRICE would require the STATUS be set to OFFER rather

than ACCEPTED (see item c).

f. The Customer agrees to the OFFERlPRICE and sets the STATUS to CONFIRM via the transcust Template.

g. The OFFERlPRICE with the STATUS as CONFIRMED locks in the terms of the reservation.

4.4.6.4 Negotiations Refused by Seller

a. The Customer submits a transmission reservation request with the BIDlPRICE less than the CEILING PRICE

via the transrequest Template. Initially the STATUS is set to QUEUED by OASIS.

b. The Seller has the option of setting the STATUS via the transsell Template to one of the following: RECEIVED,

STUDY, ACCEPTED, OFFER, or REFUSED.

c. The Seller determines that the BIDlPRICE is too low, sets OFFERlPRICE to his desired value, and sets STATUS

to OFFER via the transsell Template.

d. The Customer responds to OFFERlPRICE with updated BIDlPRICE and sets the STATUS to REBID via the

transcust Template for re-evaluation by Seller.

e. The Seller breaks off all further negotiations by setting the STATUS to REFUSED.

4.4.6.5 Negotiations Withdrawn by Customer

a. The Customer submits a transmission reservation request with the BIDlPRICE less than the CEILING PRICE

via the transrequest. Initially the STATUS is set to QUEUED by OASIS.

b. The Seller has the option of setting STATUS via the transsell Template to one of the following: RECEIVED,

STUDY, ACCEPTED, OFFER, or REFUSED.

c. The Seller determines that the BIDlPRICE is too low, sets the OFFERlPRICE to his desired value, and sets

the STATUS to OFFER via the transsell Template.

d. The Customer responds to the OFFERlPRICE with an updated BIDlPRICE and sets the STATUS to REBID

for re-evaluation by Seller.

e. The Seller determines that the BIDlPRICE is still too low, sets the OFFERlPRICE to another value, and sets

STATUS to OFFER via the transsell Template.

f. The Customer breaks off all further negotiations by setting STATUS to WITHDRAWN (or the customer/seller

could go through additional iterations of REBID/OFFER until negotiations are broken off or the reservation is CONFIRMED).

4.5 Information Supported by Web Page

There shall be a Web page on each OASIS node with information on requesting the text file of the tariffs and

service agreements.

5. Performance Requirements

A critical aspect of any system is its performance. Performance encompasses many issues, such as security, sizing,

response to user requests, availability, backup, and other parameters that are critical for the system to function as

desired. The following sections cover the performance requirements for the OASIS.

5.1 Security

Breaches of security include many inadvertent or possibly even planned actions. Therefore, several requirements

shall be implemented by the TSIPs to avoid these problems:

a. Provider Update of TS Information: Only Providers, including Secondary Providers, shall be permitted to update

their own TS Information.
38940 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

b. Customer Input Only ASCII Text: TSIPs shall be permitted to require that inputs from Customers shall be filtered

to permit only strict ASCII text (strip bit 8 from each byte).

c. Provider Updating Over Public Facilities: If public facilities are involved in the connection between a Provider

and the OASIS Node, the Provider shall be able to update his TS Information only through the use of ASCII or

through encrypted files.

d. User Registration and Login: All Users shall be required to register and login to a Provider’s Account before

accessing that Provider’s TS Information.

e. User Passwords: All Users shall enter their personal password when they wish to access to TS Information

beyond the lowest Access Privilege.

f. Service Request Transactions: Whenever Service Request transactions are implemented entirely over the OASIS,

both an individual Customer password for the request, and an individual Provider password for the notification of

acceptance shall be required.

g. Data Encryption: Sophisticated data encryption techniques and the ‘‘secure id’’ mechanisms being used on the

public Internet shall be used to transfer sensitive data across the Internet and directly between OASIS Nodes.

h. Viruses: Since only data is being transmitted between the OASIS Nodes and the Users, viruses are unlikely

to be passed between them. Therefore, TSIPs shall be responsible for ensuring that the OASIS Nodes are free from

viruses, but need not screen data exchanges with Users for viruses.

i. Performance Log: TSIPs shall keep a log on User usage of OASIS resources.

j. Disconnection: TSIPs shall be allowed to disconnect any User who is degrading the performance of the OASIS

Node through the excessive use of resources, beyond what is permitted in their Service Level Agreement.

k. Premature Access: The TSIP log shall also be used to ensure that Users who are affiliated with the Provider’s

company (or any other User) do not have access to TS information before it is publicly available.

l. Firewalls: TSIPs shall employ security measures such as firewalls to minimize the possibility that unauthorized

users shall access or modify TS Information or reach into Provider or User systems. Interfaces through Public Data

Networks or the Internet shall be permitted as long as these security requirements are met.

m. Certificates and Public Key Standards (optional): Use of alternative forms of login and authentication using

certificates and public key standards is acceptable.

5.2 Access Privileges

Users shall be assigned different Access Privileges based on external agreements between the User and the Provider.

These Access Privileges are associated with individual Users rather than just a company, to ensure that only authorized

Users within a company have the appropriate access.

The following Access Privileges shall be available as a minimum:

a. Access Privilege Read-Only: The User may only read publicly available TS Information.

b. Access Privilege for Transactions: The Customer is authorized to transact Services Requests.

c. Access Privilege Read/Write: A Secondary Provider shall have write access to his own Provider Account on

an OASIS Node.

5.3 OASIS Response Time Requirements

TSIPs can only be responsible for the response capabilities of two portions of the Internet-based OASIS network:

• The response capabilities of the OASIS Node server to process interactions with Users.

• The bandwidth of the connection(s) between the OASIS Node server and the Internet.

Therefore, the OASIS response time requirements are as follows:

a. OASIS Node Server Response Time: The OASIS Node server shall be capable of supporting its connection(s)

to Users with an average aggregate data rate of at least ‘‘A’’ bits per second. ‘‘A’’ is defined as follows:

A=N *R bits/sec

where:

N=5% of registered Customers.

and

R=28,800 bits/sec per Customer.

b. OASIS Node Network Connection Bandwidth: The bandwidth ‘‘B’’ of the OASIS Node connection(s) to the Internet

shall be at least:

B=2 * A bits/sec

c. Time to Meet Response Requirements: The minimum time responses shall be met within 1 month of User registration

for any single new User. If more than 10 new Users register in one month, 2 months lead time shall be permitted

to expand/upgrade the OASIS Note to meet the response requirements.

5.4 OASIS Provider Account Availability

The following are the OASIS Provider Account availability requirements:

a. OASIS Provider Account Availability: The availability of each OASIS Provider account on a OASIS Node shall

be at least 98.0% (downtime of about 7 days per year).

Availability is defi

Total Time

ned as:

% Availability = (1 Cumulative Provider Account Downtime) − *100

A Provider account shall be considered to be down, and downtime shall be accumulated, upon occurrence of any

of the following:
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38941

1. One or more Users cannot link and log on to the Provider account. The downtime accumulated shall be calculated

as:

Σ for affected Users of 1/n * (Login time), which is the time used by each affected User to try to link and log

on to the Provider account, and where ‘‘n’’ is the total number of Users actively registered for that Provider account.

2. One or more Users cannot access TS Information once they have logged on to a Provider account. The downtime

accumulated shall be calculated as:

Σ for affected Users of 1/n * (Access Time), which is the time used by each affected User to try to access data,

and where ‘‘n’’ is the total number of Users actively registered for that Provider.

3. A five (5) minute penalty shall be added to the cumulative downtime for every time a User loses their connection

to a Provider’s account due to an OASIS Node momentary failure or problem.

5.5 Backup and Recovery

The following backup and recovery requirements shall be met:

a. Normal Backup of TS Information: Backup of TS Information and equipment shall be provided within the OASIS

Node so that no data or transaction logs are lost or become inaccessible by Users due to any single point of failure.

Backed up data shall be no older than 30 seconds. Single points of failure include the loss of one:

• Disk drive or other storage device

• Processor

• Inter-processor communications (e.g., LAN)

• Inter-OASIS communications

• Software application

• Database

• Communication ports for access by Users

• Any other single item which affects the access of TS Information by Users

b. Spurious Failure Recovery Time: After a spurious failure situation, all affected Users shall regain access to all

TS Information within 30 minutes. A spurious failure is a temporary loss of services which can be overcome by rebooting

a system or restarting a program. Permanent loss of any physical component is considered a catastrophic failure.

c. Long-Term Backup: Permanent loss of critical data due to a catastrophic failure shall be minimized through

off-line storage on a daily basis and through off-site data storage on a periodic basis.

d. Catastrophic Failure Recovery: Recovery from a catastrophic failure or loss of an OASIS Node may be provided

through the use of alternate OASIS Nodes which meet the same availability and response time requirements. TSIPs

may set up prior agreements with other TSIPs as to which Nodes will act as backups to which other Nodes, and

what procedure will be used to undertake the recovery. Recovery from a catastrophic failure shall be designed to

be achieved within 24 hours.

5.6 Time Synchronization

The following are the time requirements:

a. Time Synchronization: Time shall be synchronized on OASIS Nodes such that all time stamps will be accurate

to within ‘‘0.5 second of official time. This synchronization may be handled over the network using NTP, or may

be synchronized locally using time standard signals (e.g. WWVB, GPS equipment).

b. Network Time Protocol (NTP): OASIS Nodes shall support the Internet tool for time synchronization, Network

Time Protocol (NTP), which is described in RFC–1350, version 3, so that Users shall be able to request the display

and the downloading of current time on an OASIS node for purposes of user applications which might be sensitive

to OASIS time.

5.7 TS Information Timing Requirements

The TS Information timing requirements are as follows, except they are waived during emergencies.

a. TS Information Availability: The most recent Provider TS information shall be available on the OASIS Node

within 5 minutes of its required posting time at least 98% of the time. The remaining 2% of the time the TS Information

shall be available within 10 minutes of its scheduled posting time.

b. Notification of Posted or Changed TS Information: Notification of TS Information posted or changed by a Provider

shall be made available within 60 seconds of the log.

c. Acknowledgment by the TSIP: Acknowledgment by the TSIP of the receipt of User Purchase requests shall occur

within 1 minute. The actual negotiations and agreements on Purchase requests do not have time constraints.

5.8 TS Information Accuracy

The following requirements relate to the accuracy of the TS information:

a. TS Information Reasonability: TS information posted and updated by the Provider shall be validated for reasonability

and consistency through the use of limit checks and other validation methods.

b. TS Information Accuracy: Although precise measures of accuracy are difficult to establish, Providers shall use

their best efforts to provide accurate information.

5.9 Performance Auditing

The following are the performance auditing requirements:

a. User Help desk Support: TSIPs shall provide a ‘‘Help Desk’’ that is available at least during normal business

hours (local time zone) and normal work days.

b. Monitoring Performance Parameters: TSIPs shall use their best efforts to monitor performance parameters. Any

User shall be able to read or down load these performance statistics.

5.10 Migration Requirements

Whenever a new version of the S&CP is to be implemented, a migration plan will be developed for cutting over

to the new version.
38942 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

Appendix A—Data Element Dictionary

Version 1.2

May 27, 1998

Data dictionary element

name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

AFFILIATElFLAG .............. AFFLAG ...... 1(ALPHANUMERIC)3 ........ Valid Values .....................

YES ..................................

NO ....................................

Set to YES if customer is an affiliate of

the provider.

ANClSERVICElTYPE ..... ANCTYPE ... 1(ALPHANUMERIC)20 ...... Valid types ........................ El—Energy Imbalance.

• EL ................................. EP—Spinning Reserve.

• SP ................................. SU—Supplemental Reserve.

• SU ................................. RV—Reactive supply and Voltage

Control.

• RV ................................. RF—Regulation and Frequency response.

• RF ................................. SC—Scheduling, system Control and

Dispatch.

• SC ................................. (Registered) must be registered with

www.tsin.com and listed in the

ANCSERV template.

• (Registered)

NAClSVClLINK ............... ANCSVCLINK.1(ALPHANUMERIC)300 .... Formatted string as follows:

SC:(AA); RV: (AA); RF:

(AA[:xxx[:yyy[:nnn]]]);

EL:

(AA[:xxx[:yyy[:nnn]]]);

SP:

(AA[:xxx[:yyy[:nnn]]]);

SU:

(AA[:xxx[:yyy[:nnn]]]);

(Registered):

(AA[:xxx[:yyy[:nnn]]]);

The method for linking ancillary services to a transmission service request. The provider and capacity of

each ancillary service is identified

using the formated string:

SC:(AA); RV:(AA); RI:[:xxx[:yyy[:nnn]]]);

El:

(AA[:xxx[:yyy[:nnn]]]);

SP:(AA[:xxx[:yyy[:nnn]]]);

[Registered):(AA[:xxx[:yyy[:nnn]]])

where AA is the appropriate PRIMARYlPROVIDERlCODE, SELLERlCODE; or CUSTOMERlCODE, and represents the

company providing the ancillary

services. ‘‘AA’’ may be unspecified

for ‘‘xxx’’ type identical to ‘‘FI’’, in

which case the ‘‘:’’ character must

be present and precede the ‘‘FI’’

type.

If multiple ‘‘AA’’ terms are necessary,

then each ‘‘AA’’ grouping will be enclosed within parenthesis, with the

overall group subordinate to the

ANClSVClTYPE: specified within

parenthesis.

and where xxx represents either:

—‘‘FT’’ to indicate that the Customer

will determine ancillary services at a

future time, or

—‘‘SI’’ to indicate tht the Customer will

self-provide the ancillary services, or

—‘‘RQ’’ to indicate that the Customer

is asking the OASIS to initiate the

proecess for making an ancillary

services reservation with the indicated Provider or Seller on behalf of

the Customer. The Customer must

then continue the reservation process with the Provider or Seller. If the

transmission services request is for

preconfirmed service, then the ancillary services shall also be

preconfirmed, or

—‘‘AR’’ to indicate an assignment reference number sequence follows.
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38943

Data dictionary element

name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

The terms ‘‘yyy’’ and ‘‘nnn’’ are subordinate to the xxx type of ‘‘AR’’ yyy

represents the ancillary services reservation number (ASSIGNMENTlREF) and nnn represents

the capacity of the reserved ancillary

services. Square brackets are used

to indicate optional elements and are

not used in the actual linkage itself.

Specifically, the :yyy is applicable to

only the ‘‘AR’’ term and the :nnn

may optionally be left off if the capacity of ancillary services is the

same as for the transmission services, and optionally multiple ancillary

reservations may be indicated by additional (xxx[:yyy[:nnn]]) enclosed

within parenthesis. If no capacity

amount is indicated, the required capacity is assumed to

ANClSVClREQ ............... ANCSVCREQ.1(ALPHANUMERIC)100 .... EI: (M.R.O.U); SP;

(M.R.O.U);.

SU: (M.R.O.U);

RV: (M.R.O.U):

RE: (M.R.O.U);

SC: (M.R.O.U):

(registered): (M.R.O.U)

Ancillary services required for a transmission services offering. The appropriate letter (M.R.O.U) will be assigned to each of the six Proforma

FERC ancillary services (see

ANClSERVICElTYPE), where the

letters mean the following:

(M) Mandatory, which implies that the

Primary Provider must provide the

ancillary service (R) Required, which

implies that the ancillary service is

required, but not necessarily from

the Primary Provider (O) Optional,

which implies that the ancillary service is not necessarily required, but

could be provided

(U) Unknown, which implies that the

requirements for the ancillary service

are not know at this time.

ALTERNATElSERVICElFLAG.ALTSVCFLG 2(ALPHANUMERIC)3 ........ Defaulted to ‘‘YES’’ .......... Used as a flag to identify this reservation as a NON-FIRM use of FIRM

transmission services on an alternate point of delivery.

ASSIGNMENTUlREF ........ AREF .......... 1(ALPHANUMERIC)12 ...... Unique value .................... A unique reference number assigned

by a Transmission Information Provider to provide a unique record for

each transmission or ancillary service request. A single transmission or

ancillary service request will be over

a contiguous time period, i.e. from a

STARTlTIME to an STOPlTIME.

BIDlPRICE ........................ BIDPR ......... 1(NUMERIC)5 +‘‘,’’ +

2(NUMERIC)12.

Positive number with 2

decimals.

The current bid price of a Service in

dollars and cents. Used by Customers to designate a price being

bid.

CAPACITY ........................... CAP ............. 1(NUMERIC)12 .................. Non-negative number in

units of MW.

Transfer capability is the measure of

the ability of the interconnected electric system to readily move or transfer power from one area to another

over all transmission lines (or paths)

between those areas under specified

system conditions. In this context

‘‘area’’ may be an individual electric

system, powerpool, control area,

subregion, or NERC region or portion thereof.

CAPACITYlCURTAILED ... CAPCUR ..... 1(NUMERIC)12 .................. Non-negative number in

units of MW.

The amount of transfer capability curtailed by the Primary provider for

emergency reasons.

CAPACITYlSCHEDULED CAPSCH ..... 1(NUMERIC)12 .................. Non-negative number in

units of MW.

Transfer capability scheduled on each

path.
38944 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

Data dictionary element

name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

CATEGORY ......................... CAT ............. 1(ALPHANUMERIC)25 ...... Valid name from CATEGORY in LIST Template.A name to be used to categorize messages. Valid names would include:

Disocunt, Want-Ad, Curtailment,

Outage, Oasis Maint Notice.

CEILINGlPRICE ................ CEILPR ....... 1(NUMERIC)5 + ‘‘.’’ +

2(NUMERIC)2.

Positive number with 2

decimals.

Ceiling price of the Service as entered

by the Transmission Provider.

COLUMNlHEADERS ........ HEADERS ... 1(ALPHANUMERIC) Limited to all the elements

names in one Template.

Headers surrounded with

A and separated by

commas. Limited to

valid Template element

names. Must use full

element name and not

alias.

Example: COLUMNlHEADER=

APATHlNAME’’,

‘‘POINTlOFlRECEIPT’’, POINTl

OFlDELIVERY’’, ‘‘SOURCE’’,

‘‘SINK’’.

CONTINUATIONlFLAG .... CONT .......... 1(ALPHANUMERIC)1 ........ ‘‘Y’’ OR ‘‘N’’ ...................... Indicates whether or not this record is

a continuation from the previous

record.

CONTROLlAREA .............. AREA .......... 1(ALPHANUMERIC)20 ...... Valid name of a control

area.

A part of the power system with metered tie lines and capable of matching generation and load while meeting scheduled interchange. Location

of Ancillary Services is my CONTROLlAREA.

CURTAILMENTlOPTIONS CUROPT ..... 1(ALPHANUMERIC)80 ...... Free form text ................... Customer options, if any, to avoid curtailment.

CURTAILMENTlPROCEDURES.CURPROC .. 1(ALPHANUMERIC)80 ...... Free form text ................... Curtailment procedures to be followed

in the event of a curtailment.

CURTAILMENTlREASON CURREAS .. 1(ALPHANUMERIC)80 ...... Free form text ................... Reason for curtailment of service.

CUSTOMERlCODE .......... CUST .......... 1(ALPHANUMERIC)6 ........ Unique value, registered

on TSIN.COM.

Any entity (or its designated agent)

that is eligible to view OASIS information, to execute a service agreement, and/or to receive transmission

service.

CUSTOMERlCOMMENTS CUSTCOM .. 1(ALPHANUMERIC)80 ...... Free-form text ................... Informative text.

CUSTOMERlDUNS .......... CUSTDUNS 9(NUMERIC)9 .................... Unique DUNS number ..... Unique DUNS number for a Customer.

CUSTOMERlEMAIL .......... CUSTEMAIL 1(ALPHANUMERIC)25 ...... Valid Internet E-Mail address.Internet E-Mail address of Customer

contact person.

CUSTOMERlFAX .............. CUSTEFAX 14(ALPHANUMERIC)20 .... Area code and telephone

number, plus any extensions (aaa)-nnn-nnnn

xnnnn.

Fax phone number of Customer contract person.

CUSTOMERlNAME .......... CUSTNAME 1(ALPHANUMERIC)25 ...... Free form text ................... Name of Customer contract person.

CUSTOMERlPHONE ........ CUSTPHON 14(ALPHANUMERIC)20 .... Area code and telephone

number, plus any extensions (aaa)-nnn-nnnn

xnnnn.

Telephone of Customer contact person.

DATAlROWS .................... ROWS ......... 1(NUMERIC) unlimited ....... Positive Number ............... Number of records (rows) of data exclusive of header information that

are to be uploaded or downloaded in

a file.

DATElTIMElEFFECTIVE TIMEEFCT .. 16(ALPHANUMERIC)16 .... Valid date and time in

seconds

yyyy+mo+dd+hh

+mm+ss+tz.

Date and time a message or service

offer is in effect.

DATElTIMElPOSTED ..... TIMEPSTD .. 16(ALPHANUMERIC)16 .... Valid date and time in

seconds

yyyy+mo+dd+hh

+mm+ss+tz.

Date and time to seconds a message

or service offered was posted.

DEALlREF ......................... DREF .......... 1(ALPHANUMERIC) 12 ..... Unique value, Assigned by

Customer.

The unique reference assigned by a

Customer to two or more service

purchases to identify each of them

as related to others in the same

power service deal. These requests

may be related to each other in time

sequence through a single Provider,

or as a series of wheels through

multiple Providers, or a combination

of both time and wheels. The User

uses the DEALlREF to uniquely

identify a combination of requests

relating to a particular deal.

DISCRETIONlDESCRIPTION.DISCDESC 0(ALPHANUMERIC)1000 .. Free form text ................... A detailed description of the discretion

being reported.
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38945

Data dictionary element

name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

ELEMENTlNAME .............. ELEMENT ... 1(ALPHANUMERIC)40 ...... Valid Template element

name.

Template element name as indicated

in data dictionary.

EMPLOYEElNAME ........... EMPNAME .. 1(ALPHANUMERIC)25 ...... Free form text ................... Name of person who is transferring

from one position to another.

ERRORlMESSAGE .......... ERROR ....... 1(ALPHANUMERIC)250 .... Free form text ................... Error message related to a

RECORDlSTATUS or REQUESTlSTATUS.

FORMERlCOMPANY ....... FORMCO .... 1(ALPHANUMERIC)25 ...... Free form text ................... Former company of the person who is

transferring.

FORMERlDEPARTMENT FORMDEPT 1(ALPHANUMERIC)25 ...... Free form text ................... Former department of the person who

is transferring.

FORMERlPOSITION ........ FORMPOS .. 1(ALPHANUMERIC)25 ...... Free form text ................... Former position held by the person

who is transferring.

INTERFACElTYPE ........... INTERFACE 1(ALPHANUMERIC)1 ........ I,E ..................................... Type of interface define by path: Internal (I) to a control area or External

(E) to a control area.

LISTlITEM ......................... ITEM ........... 1(ALPHANUMERIC)50 ...... Free form text ................... Item from list, such as list of SELLERs,

list of PATHs, list of PORs, list of

PODs, Lists of SERVICElINCREMENT, TSlCLASS,

TSlTYPE, TSlPERIOD, NERCl

CURTAILMENTlPRIORITY,

OTHERlCURTAILMENTl PRIORITY, SERVICElINCREMENT, CATEGORY List of TEMPLATEs.

LISTlITEMl DESCRIPTION.ITEMDESC 0(ALPHANUMERIC)100 .... Free form text ................... A detailed description of the

LISTlITEM.

LISTlNAME ....................... LIST ............ 1(alphanumeric)25 ............. LIST, SELLER, PATH,

POR, POD, SERVICElINCREMENT,

TSlCLASS,

TSlTYPE,

TSlPERIOD,

TSlSUBCLASS, ANCILLARYlSERVICElTYP

E, CATEGORY, TEMPLATE.

List of valid names for each of the

types of lists. The minimum set of

lists defined must be implemented.

MESSAGE ........................... MSG ............ 1(ALPHANUMERIC)200 .... Free form text ................... An informative text message.

NEGOTIATEDlPRICElFLAG.NGPRIFLG .. 1(ALPHANUMERIC)1 ........ H, L, or blank .................... Set to H if OFFERlPRICE is higher

than the currently posted price; set

to L if OFFERlPRICE is lower than

the currently posted price.

NERClCURTAILMENTl

PRIORITY.

NERCURT .. 1(NUMERIC)1 .................... Integer 1–7 ....................... One of the NERC seven curtailment

priorities, documented in LIST

templat.

NEWlCOMPANY ............... NEWCO ...... 1(ALPHANUMERIC)25 ...... Free form text ................... New company of the person who is

transferring.

NEWlDATA ....................... NEWDATA .. 1(ALPHANUMERIC)200 .... Any valid date element

value.

For audit log, the new updated value

of a Template data element after update.

NEWlDEPARTMENT ........ NEWDEPT .. 1(ALPHANUMERIC)25 ...... Free form text ................... New department of the person who is

transferring.

NEWlPOSITION ................ NEWPOS .... 1(ALPHANUMERIC)25 ...... Free form text ................... New position held by the person who

is transferring.

OFFERlPRICE .................. OFFPR ........ 1(NUMERIC)5 + ‘‘.’’ +

2(NUMERIC)2.

Positive number with 2

decimals.

The current offered price of a Service

in dollars and cents. Used by the

Seller to indicate the offering price.

OFFERlSTARTlTIME ..... OFFSTIME .. 16(ALPHANUMERIC)16 .... Valid Date and Time to

seconds:

yyy+mo+dd+hh+mmm+

ss+tz.

Start time of the window during which

a Customer may request a discounted offer.

OFFERl STOPlTIME ...... OFFSPTIME 16(ALPHANUMERIC)16 .... Valid Date and Time to

seconds:

yyyy+mo+dd+hh ...............

+mm+ss+tz .......................

Stop time of the window during which

a Customer may request a discounted offer. (Expiration time of an

offer).

OLDlDATA ........................ OLDDATA ... 1(ALPHANUMERIC)200 .... Any valid data element

value.

For audit log, the old value of a Template data element prior to being updated. This element is not applicable

in the audit log for transaction

events.
38946 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

Data dictionary element

name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

OPTIONALlCODE ............. N/A .............. 0(ALPHANUMERIC)25 ...... Unique path name within

region.

OPTIONALlCODE—25 chars, unique

for Path. If used for directionality,

then the first 12 characters shall represent POR, followed by >->, followed by 12 characters which shall

represent POD. Used by

PATHlNAME.

OTHERlCURTAILMENT

lPRIORITY.

OTHCUR ..... 0(ALPHANUMERIC)8 ........ Free form tect ................... Other than NERC curtailment priorities,

such as regional curtailment priorities. Suggested format

region+number, for example

MAPP4, WSCC7. Documented in

LIST template.

OUTPUTlFORMAT ........... FMT ............. 4(ALPHANUMERIC)4 ........ HTML, DATA .................... Format of response:

HTML = hypertext markup language

for presentation using a web browser

DATA = text for use in a downloaded

file.

PATHlCODE ..................... N/A .............. 0(ALPHANUMERIC)12 ...... Unique code for each path

as defined by primary

provider.

Unique code within a Region for each

path. Used by PATHlNAME.

PATHlNAME ..................... PATH .......... 5(ALPHANUMERIC)50 ...... Unique value .................... The unique name assigned to a single

transmission line or the set of one or

more parallel transmission lines

whose power transfer capabilities

are strongly interrelated and must be

determined in aggregate. These

lines are typically described as being

on a path, corridor or interconnection

in some regions, or as crossing an

interface or cut-plane in other regions. Multiple lines may be owned

by different parties and require prorating of capability shares.

The name is constructed from the following codes, with each code separated by a ‘‘/’’. Trailing ‘‘/’’ may be

omitted, if there are no values for

OPTIONlCODE and

SPARElCODE:

REGIONlCODE—2 chars, unique to

OASIS System

PRIMARYlPROVIDERlCODE—4

chars, unique within Region

PATHlCODE—12 chars, unique for

Primary Provider

OPTIONALlCODE—25 chars, unique

for Path. If used for directionality,

then the first 12 characters shall represent POR, followed by >->, followed by 12 characters which shall

represent POD SPARElCODE—3

chars.

POINTl OFlDELIVERY ... POD ............ 1(ALPHANUMERIC)12 ...... Unique value within Primary Provider.Point of Delivery is one or more

point(s) of interconnection on the

Transmission Provider’s transmission system where capacity and/

or energy transmitted by the Transmission Provider will be made available to the Receiving Party. This is

used along with Point of Receipt to

define a Path and direction of flow

on that path. For internal paths, this

would be a specific location(s) in the

area. For an external path, this may

be an area-to-area interface.
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38947

Data dictionary element

name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

POINTlOF lRECEIPT ..... POR ............ 1(ALPHANUMERIC)12 ...... Unique value within Primary Provider.Point of Receipt is one or more

point(s) of interconnection on the

Transmission Provider’s transmission system where capacity and/

or energy transmitted will be made

available to the Transmission Provider by the Delivering Party. This is

used along with Point of Delivery to

define a Path and direction of flow

on that path. For internal paths, this

would be a specific location(s) in the

area. For an external path, this may

be an area-to-area interface.

POSTINGlNAME ............... POSTNAME 1(ALPHANUMERIC)25 ...... Free form text ................... Name of person who is posting the information on the OASIS.

POSTINGlREF .................. POSTREF ... 1(ALPHANUMERIC)12 ...... Unique Value .................... Assigned by TSIP when Service or

Message is received by TSIP.

Unique number can be used by the

user to modify or delete the posting.

PRECONFIRMED ................ PRECONF .. 2(ALPHA)3 ......................... YES or NO ....................... Used by Customer to preconfirm sale

in Template transrequest or

ancrequest. If customer indicates

sale is preconfirmed, then the response is YES and the customer

does not need to confirm the sale.

PRICElUNITS ................... UNITS ......... 1(ALPHA)20 ....................... Free form text ................... The units used for CEILINGlPRICE,

OFFERlPRICE, and BIDlPRICE.

Examples: $/MWhr, $/MWmonth

PRIMARYl PROVIDERlCOMMENTS.PPROVCOM 1(ALPHANUMERIC)80 ...... Free form text ................... Informative text. Usually entered by the

Primary Provider through a back end

system.

PRIMARYl PROVIDERlCODE.PROVIDER 1(ALPHANUMERIC)4 ........ Unique code ..................... Unique code for each Primary Provider. Used by PATHlNAME and in

URL. Registered as part of URL at

www.tsin.com.

PRIMARYl PROVIDERlDUNS.PPROV- ......

DUNS ......

9(NUMERIC)9 .................... Valid DUNS number ......... Unique code for each Primary. Provided by Dun and Bradstreet.

REASSIGNEDl CAPACITY RASCAP ..... 1(NUMERIC)12 .................. Positive number, cannot

exceed previous assigned capacity.

The amount of transfer capability that

was reassigned from one entity to

another.

REASSIGNEDl REF ......... REREF ........ 1(ALPHANUMERIC)12 ...... Unique value .................... When customer makes a purchase of

a transmission service that was

posted for resale and a new ASSIGNMENTlREF number is issued

the previous ASSIGNMENTlREF

number now becomes the REASSIGNMENTlREF. Also used by

SELLER when posting transmission

or ancillary services for resale to

show the previous assignment reference number. Also used by the

customer when making a request to

use FIRM service as NON-FIRM

over alternate points of delivery.

REASSIGNEDlSTARTlTIME.RESSTIME .. 16(ALPHANUMERIC)16 .... Valid date and time to

seconds:

yyy+mo+dd+hh+tz

Beginning date and time of the reassigned transmission service.

REASSIGNEDlSTOPlTIME.RESSPIME 16(ALPHANUMERIC)16 .... Valid date and time to

hour:

yyyy+mo+dd+hh+tz

Date and time of the end of the transmission service that is reassigned to

another User.

RECORDlSTATUS ........... REC- ...........

STATUS ..

1(NUMERIC)3 .................... Error number .................... Record status indicating record was

successful or error code if unsuccessful.

200=Successful
38948 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

Data dictionary element

name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

REGIONlCODE ................. N/A .............. 1(ALPHANUMERIC)2 ........ Unique within OASIS System.Defined for NERC regions, with the following defined:

E—ECAR.

I—MAIN.

S—SERC.

T—ERCOT.

A—MAPP.

P—SPP.

M—MAAC.

N—NPCC.

W—WSCC.

Second character or digit reserved for

subregion id as defined by each region.

REQUESTlREF ................. RREF .......... 1(ALPHANUMERIC)12 ...... Unique value .................... A reference uniquely assigned by a

Customer to a request for service

from a Provider.

REQUESTlSTATUS .......... RSTATUS ... 1(NUMERIC)3 .................... Error number .................... Message status indicating message

was successful (if all

RECORDlSTATUS show success)

or error code if any

RECORDlSTATUS showed unsuccessful.

200=Successful.

RESPONSElTIMElLIMIT RESPTL ...... 16(ALPHANUMERIC)16 .... Valid date and time to

seconds:

yyyy+mo+dd+hh

+mm+ss+tz

Date and time to seconds by when a

response must be received from a

Customer.

RESPONSIBLElPARTYlNAME.PARTNAME 1(ALPHANUMERIC)25 ...... Free form text ................... The name of the person responsible

for granting the discretion.

RETURNlTZ ...................... TZ ................ 2(ALPHANUMERIC)2 ........ AD, AS, PD, PS, ED, ES,

MD, MS, CD, CS, UT.

A time zone code, indicating the base

time zone, and whether daylight saving time is to be used. This field may

be set by a Customer in a query.

Returned date and time data is converted to this time zone.

SALElREF ......................... SREF .......... 1(ALPHANUMERIC)12 ...... Unique value .................... Identifier which is set by seller (including Primary Provider) when posting

a service for sale.

SELLERlCODE ................. SELLER ...... 1(ALPHANUMERIC)6 ........ Unique value .................... Organization name of Primary Provider

or Reseller.

SELLERlCOMMENTS ...... SELCOM ..... 1(ALPHANUMERIC)80 ...... Free form text ................... Informative text provided by the Seller.

SELLERlDUNS ................. SELDUNS ... 9[NUMERIC]9 ..................... Valid DUNS number ......... Unique Data Universal Numbering

System provided by Dun and Bradstreet. Code for a Primary Provider

or Seller.

SELLERlEMAIL ................. SELEMAIL .. 5[ALPHANUMERIC]60 ....... Valid network reference ... E-Mail address of Seller contact person.

SERVICElINCREMENT .... SRVINCR .... 1[ALPHANUMERIC]8 ......... Valid increments ...............

• HOURLY

• Daily

• Weekly

• Monthly

• Yearly

• [Registered]

The transmission service increments

provided. Five are pre-defined, while

additional increments can be used if

they are registered on TSIN.COM

and shown in the Provider’s LIST

template.

SELLERlFAX .................... SELFAX ...... 14[ALPHANUMERIC]20 ..... Area code and telephone

number, plus any extensions Example: (aaa)-

nnn-nnnn-xnnnn.

The fax telephone number for contact

person at Seller.

SELLERlNAME ................. SELNAME ... 1[ALPHANUMERIC]25 ....... Free form text ................... The name of an individual contact person at the Seller.

SELLERlPHONE ............... SELPHONE 14[ALPHANUMERIC]20 ..... Area code and telephone

number, plus any extensions (aaa)-nnn-nnnn

xnnnn.

The telephone number of a contact

person as a Seller.

SERVICElDESCRIPTION SVCDESC ... 1[ALPHANUMERIC]200 ..... Free-form text ................... Information regarding a service.

SERVICElNAME ............... SVCNAME .. 1[ALPHANUMERIC]25 ....... Free-form text ................... Name of service affected by the discretionary action.

SERVICElTYPE ................ SVCTYPE ... 1[ALPHANUMERIC]25 ....... Free-form text ................... Type of service affected by the discretionary action.

SINK .................................... SINK ............ 0[ALPHANUMERIC]14 ....... Valid area name ............... The area in which the SINK is located.
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38949

Data dictionary element

name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

SOURCE ............................. SOURCE ..... 0[ALPHANUMERIC]14 ....... Valid area name ............... The area in which the SOURCE is located.

SPARElCODE ................... N/A .............. 0[ALPHANUMERIC]3 ......... Defined by region ............. Spare code to be used at a later time.

Used by PATHlNAME.

STANDARDSlOFl CONDUCTlISSUE.STDISSUE .. 0[ALPHANUMERIC]200 ..... Free-form text ................... Issues that were in violation of the

FERC Standards of Conduct.

STARTlTIME ..................... STIME ......... 16[ALPHANUMERIC]16 ..... Valid Date and Time to

seconds:

yyyy+mo+dd+hh

+mm+ss+tz

Start date and clock time of a service.

When used as a query variable, it

requires the return of all items

whose Stop time is after the Start

time.

Note that for some Templates when

used as a query variable the time

may be only valid up to the hour,

day or month. If more data is given

than is valid, the hour, day or month

will be used to make the date and

time inclusive, i.e. date or time will

be truncated to valid hour, day or

month.

STARTlTIMElPOSTED .. STIMEP ....... 16[ALPHANUMERIC]16 ..... Valid Date and Time to

seconds:

yyyy+mo+dd+hh

+mm+ss+tz

Query parameter to indicate all the

records are to be retrieved that were

posted on or after this time.

STARTlTIMElQUEUED .. STIMEQ ...... 16[ALPHANUMERIC]16 ..... Valid Date and Time to

seconds:

yyyy+mo+dd+hh

+mm+ss+tz

Start date and clock time of a service,

used for requesting transactions

queued after this time.

STATUS ............................... STATUS ...... 5(ALPHANUMERIC)25 ...... Valid field (QUEUED, RECEIVED, STUDY,

REBID, OFFER, ACCEPTED, REFUSED,

CONFIRMED, WITHDRAWN, DISPLACED,

ANNULLED, RETRACTED).

QUEUED=initial status assigned by

TSP on receipt of ‘‘customer capacity purchase request’’.

RECEIVED=reassigned by TP to acknowledge QUEUED requests and

indicate the service request is being

evaluated.

STUDY=assigned by TP to indicate

some level of study is required or

being performed to evaluate service

request.

OFFER=assigned by TP to indicate

that a OFFERlPRICE is being proposed.

REBID=assigned by TC to indicate a

new BIDlPRICE is being proposed.

ACCEPTED=assigned by TP to indicate service request has been approved/accepted. If the reservation

request was submitted

PRECONFIRMED, OASIS shall immediately set the reservation status

to CONFIRMED. Depending upon

the type of ancillary services required, the Seller may or may not require all ancillary service reservations to be completed before accepting a request.

REFUSED=assigned by TP to indicate

service request has been denied,

SELLERlCOMMENTS should be

used to communicate reason for denial of service.

CONFIRMED=assigned by TC in response to TP posting ‘‘ACCEPTED’’

status to confirm service.

WITHDRAWN=assigned by TC at any

point in request evaluation to withdraw the request from any further

action.
38950 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

Data dictionary element

name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

DISPLACED=assigned by TP when a

‘‘CONFIRMED’’ request from a TC is

displaced by a longer term request

and the TC has exercised right of

first refusal (i.e. refused to match

T&Cs of new request).

ANNULLED=assigned by TP when, by

mutual agreement with the TC, the

transaction is to be voided.

RETRACTED=assigned by TP when

the TC fails to confirm or withdraw

the transaction within the required

time period.

STATUSlCOMMENTS ...... STACOM ..... 1(ALPHANUMERIC)80 ...... Free form text ................... Informative text.

STATUSlNOTIFICATION .. STATNOT ... 1(ALPHANUMERIC)200 .... http://URL:portnumber/director y/cgi script/query

parameters or Mailto:

<e-mail address.>.

The STATUSlNOTIFICATION data

element shall contain the protocol

field ‘‘http:’’, which designates the

notification method/protocol to be

used, followed by all resource location information required; the target

domain name and port designations

shall be inserted into the notification

URL based on the Customer’s Company registration information. The resource location information may include directory information, cgi script

identifiers and URL encoded query

string name/value pairs as required

by the Customer’s application, or

mailto and email address for the status information the Customer wants

to receive upon a change in STATUS of transstatus, or ancstatus.

STOPlTIME ....................... SPTIME ....... 16(ALPHANUMERIC)16 .... Valid date and time

yyyy+mo+dd+hh+mm+

ss+tz.

Stop date and clock time. When used

as a query variable, it requires the

return of all items which start before

the Stop time.

Note that for some Template when

used as a query variable the time

may be only valid up to the hour,

day or month. If more data is given

than is valid, the hour, day or month

will be used to make the date and

time inclusive, i.e. date or time will

be increased to include

STOPlTIME.

STOPlTIMElPOSTED .... STPTIMEP .. 16(ALPHANUMERIC)16 .... Valid date and time to

seconds:

yyyy+mo+dd+hh+mm+

ss+tz.

Query parameter to indicate all the

records are to be retrieved that were

posted on or before this time.

STOPlTIMElQUEUED .... SPTIMEQ .... 16(ALPHANUMERIC)16 .... Valid date and time to

seconds:

yyyy+mo+dd+hh+mm+

ss+tz.

Stop date and clock time, used for requesting transactions queued before

this time.

SUBJECT ............................ SUBJ ........... 1(ALPHANUMERIC)80 ...... Free form text ................... Informative text used to summarize a

topic in a message.

TARIFFlREFERENCE ...... TARIFF ....... 1(ALPHANUMERIC)150 .... Free form text. Name and

description of Tariff.

Tariffs approved by FERC.

TEMPLATE .......................... TEMPL ........ 1(ALPHANUMERIC)20 ...... Valid Name of Template

from Section 4.3 or from

LIST Template.

The name of a logical collection of

DATAlELEMENTS in a User’s

interaction with an OASIS Node.

TIMElOFl

LASTlUPDATE.

TLUPDATE 16(ALPHANUMERIC)16 .... Valid date and time to

seconds:

yyyy+mo+dd+hh+mm+

ss+tz.

Date and time to seconds that data

was last updated. May be used to

search data updated since a specific

point in time.

TIMElPOSTED .................. TIMEPST .... 16(ALPHANUMERIC)16 .... Valid date and time to

seconds:

yyyy+mo+dd+hh+mm+

ss+tz.

Date and time a message is posted.
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38951

Data dictionary element

name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

TIMElQUEUED ................. TIMEQ ......... 16(ALPHANUMERIC)16 .... Valid date and time to

seconds:

yyyy+mo+dd+hh+mm+

ss+tz.

Date and time that the request was

queued.

TIMElSTAMP .................... TSTAMP ..... 16(ALPHANUMERIC)16 .... Valid date and time to

seconds:

yyyy+mo+dd+hh+mm+

ss+tz.

Time data is created.

TSlCLASS ......................... TSCLASS .... 1(ALPHANUMERIC)20 ...... Valid classes: ...................

• FIRM

• NON-FIRM

• TTC

• (Registered)

The transmission service classes provided. Three are predefined, while

additional classes can be used if

they are registered on TSIN.COM

and shown in the Provider’s LIST

template page.

TSlPERIOD ....................... TSPER ........ 1(ALPHANUMERIC)20 ...... Valid periods: ....................

ONlPEAK

OFFlPEAK

FULLlPERIOD

(Registered)

The transmission service periods provided. Three are predefined, while

additional periods can be used if

they are registered on TSIN.COM

and shown in the Provider’s LIST

template.

TSlSUBCLASS ................. TSSUBC ..... 1(ALPHANUMERIC)20 ...... Free form .......................... The transmission service subclasses

provided. These are free form.

TSlTYPE ........................... TSTYPE ...... 1(ALPHANUMERIC)20 ...... Valid periods: ....................

• POINTlTOlPOINT

• NETWORK

• (Registered)

The transmission service types provided. Two are predefined, while additional types can be used if they are

registered on TSIN.COM and shown

in the Provider’s LIST template.

TSlWINDOW ..................... TSWIND ...... 1(ALPHANUMERIC)20 ...... Valid periods: ....................

• FIXED

• SLIDING

• (Registered)

The transmission service windows provided. Two are predefined, while additional windows can be used if they

are registered on TSIN.COM and

shown in the Provider’s LIST template.

TZ ........................................ TZ ................ 2(ALPHANUMERIC)2 ........ Valid time zone and indication whether daylight

savings time is to be

used.

Time zones:

Atlantic time=AD, AS.

Eastern time=ED, ES.

Central time=CD, CS.

Mountain time=MD, MS.

Pacific time=PD, PS.

Universal time=UT.

VALIDlFROMlTIME ........ VALFTIME .. 16(ALPHANUMERIC)16 .... Valid time and date

yyyy+mo+dd+hh+mm+

ss+tz.

Date and time after which the message is valid.

VALIDlTOlTIME .............. VALTTIME .. 16(ALPHANUMERIC)16 .... Valid date and time

yyyy+mo+dd+hh+mm+

ss+tz.

Date and time before which the message is valid.

VERSION ............................. VER ............. 1(REAL NUMBER)6 ........... RANGE OF 1.0 TO

9999.9.

Specifies which version of the OASIS

Standards and Communication Protocol to use when interpreting the request.

Note: This attachment will not appear in the Code of Federal Regulations.
38952 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

Attachment 3—Standards and Communication Protocols for Open Access Same-Time Information System (OASIS) (With

Revisions to OASIS How Working Group’s September 23, 1997 Submittal Highlighted)

Version 1.2

May 27, 1998

Table of Contents

1. Introduction

1.1 Definition of Terms

2. Network Architecture Requirements

2.1 Architecture of OASIS Nodes

2.2 Internet-Based OASIS Network

2.3 Communication Standards Required

2.4 Internet Tool Requirements

2.5 Navigation and Interconnectivity Between OASIS Nodes

3. Information Access Requirements

3.1 Registration and Login Requirements

3.2 Service Level Agreements

3.3 Access to Information

3.4 Provider Updating Requirements

3.5 Access to Changed Information

3.6 User Interaction With an OASIS Node

4. Interface Requirements

4.1 Information Model Concepts

4.2 OASIS Node Conventions and Structures

4.2.1 OASIS Node Naming Requirements

4.2.1.1. OASIS Node Names

4.2.1.2. OASIS Node and Primary Provider Home Directory

4.2.1.3 CGI Script Names

4.2.2 Data Element Dictionary

4.2.3 OASIS Template Constructs

4.2.3.1 Template Construction

4.2.3.2 Template Categories

4.2.3.3 Template HTML Screens

4.2.4 Query/Response Template Requirements

4.2.4.1 Query Requirements

4.2.4.2 Response Requirements

4.2.5 Input/Response Template Requirements

4.2.5.1 Input Requirements

4.2.5.2 Response to Input

4.2.6 Query Variables

4.2.6.1 General

4.2.6.2 Standard Header Query Variables

4.2.6.3 Responses to Queries

4.2.6.4 Multiple Instances

4.2.6.5 Logical Operations

4.2.6.6 Handling of Time Data Elements

4.2.6.7 Default Values

4.2.6.8 Limitations on Queries

4.2.7 CSV Format

4.2.7.1 General Record Format

4.2.7.2 Input Header Records

4.2.7.3 Response Header Records

4.2.7.4 Data Records

4.2.7.5 Continuation Records

4.2.7.6 Error Handling in CSV-Formatted Responses

4.2.8 Registration Information

4.2.8.1 General

4.2.8.2 Company Information

4.2.8.3 User Information

4.2.9 Representation of Time

4.2.9.1 General

4.2.9.2 Input Time

4.2.9.3 Output (Response) Time

4.2.10 Transaction Process

4.2.10.1 Purchase Transactions

4.2.10.2 Status Values

4.2.10.3 Dynamic Notification

4.2.10.3.1 HTTP Notification

4.2.10.3.2 E-mail Notification

4.2.11 Reference Identifiers

4.2.12 Linkage of Ancillary Services to Transmission Services

4.3 Template Descriptions

4.3.1 Template Summary

4.3.2 Query/Response of Posted Services Being Offered
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38953

4.3.2.1 Transmission Capacity Offerings Available for Purchase (transoffering)

4.3.2.2 Ancillary Services Available for Purchase (ancoffering)

4.3.3 Query/Response of Services Information

4.3.3.1 Transmission Services (transserv)

4.3.3.2 Ancillary Services (ancserv)

4.3.4 Query/Response of Schedules and Curtailments

4.3.4.1 Hourly Schedule (schedule)

4.3.4.2 Curtailment/Interruption (curtail)

4.3.5 Query/Response of Lists of Information

4.3.5.1 List (list)

4.3.6 Query/Response to Obtain the Audit log

4.3.6.1 Audit Log Information (auditlog)

4.3.7 Purchase Transmission Services

4.3.7.1 Customer Capacity Purchase Request (transrequest)

4.3.7.2 Status of Customer Purchase Request (transstatus)

4.3.7.3 Seller Approval of Purchase (transsell)

4.3.7.4 Customer Confirmation of Purchase (Input) (transcust)

4.3.7.5 Alternate Point of Receipt/Delivery (transalt)

4.3.7.6 Seller to Reassign Service Rights to Another Customer (transassign)

4.3.8 Seller Posting of Transmission Services

4.3.8.1 Seller Capacity Posting (transpost)

4.3.8.2 Seller Capacity Modify (transupdate)

4.3.9 Purchase of Ancillary Services

4.3.9.1 Customer Requests to Purchase Ancillary Services (ancrequest)

4.3.9.2 Ancillary Services Status (ancstatus)

4.3.9.3 Seller Approves Ancillary Service (ancsell)

4.3.9.4 Customer accepts Ancillary Service (anccust)

4.3.10 Seller Posting of Ancillary Services

4.3.10.1 Seller Ancillary Services Posting (ancpost)

4.3.10.2 Seller Modify Ancillary Services Posting (ancupdate)

4.3.11 Informal Messages

4.3.11.1 Provider/Customer Want Ads and Informal Message Posting Request (messagepost)

4.3.11.2 Message (message)

4.3.11.3 Provider/Sellers Message Delete Request (messagedelete)

4.3.11.4 Personnel Transfers (personnel)

4.3.11.5 Discretion (discretion)

4.3.11.6 Standards of Conduct (stdconduct)

4.4 File Request and File Download Examples

4.4.1 File Example for Hourly Offering

4.4.2 File Example for Hourly Schedule Data

4.4.3 Customer Posting a Transmission Service Offering

4.4.4 Example of Re-aggregating Purchasing Services using Reassignment

4.4.5 File Examples of the Use of Continuation Records

4.4.6 Example of Negotiation of Price

4.4.6.1 Negotiation with Preconfirmation

4.4.6.2 Negotiations without Preconfirmation

4.4.6.3 Multiple Step Negotiations

4.4.6.4 Negotiations Refused by Seller

4.4.6.5 Negotiations Withdrawn by Customer

4.5 Information Supported By Web Page

5. Performance Requirement

5.1 Security

5.2 Access Privileges

5.3 OASIS Response Time Requirements

5.4 OASIS Provider Account Availability

5.5 Backup and Recovery

5.6 Time Synchronization

5.7 TS Information Timing Requirements

5.8 TS Information Accuracy

5.9 Performance Auditing

5.10 Migration Requirements

Appendix A—Data Element Dictionary

1. Introduction

1.1 Definition of Terms

The following definitions are offered to clarify discussions of the OASIS in this document.

a. Transmission Services Information (TS Information) is transmission and ancillary services information that must

be made available by public utilities on a non-discriminatory basis to meet the regulatory requirements of transmission

open access.

b. Open Access Same-Time Information System (OASIS) comprises the computer systems and associated communications facilities that public utilities are required to provide for the purpose of making available to all transmission

users comparable interactions with TS Information.

c. Open Access Same-Time Information System Node (OASIS Node) is a subsystem of the OASIS. It is one computer

system in the (OASIS) that provides access to TS Information to a Transmission Customer.
38954 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

d. Transmission Provider (TP or Primary Provider) is the public utility (or its designated agent) that owns, operates

or controls facilities used for the transmission of electric energy in interstate commerce. (This is the same term as

is used in Part 35.3).

e. Transmission Customer (TC or Customer) is any eligible Customer (or its designated agent) that can or does

execute a transmission service agreement or can or does receive transmission service. (This is the same term as is

used in Part 35.3).

f. Secondary Transmission Provider (ST, Reseller, or Secondary Provider) is any Customer who offers to sell transmission capacity it has purchased. (This is the same as Reseller in Part 37).

g. Transmission Services Information Provider (TSIP) is a Transmission Provider or an agent to whom the Transmission

Provider has delegated the responsibility of meeting any of the requirements of Part 37. (This is the same as Responsible

Party in Part 37).

h. Value-Added Transmission Services Information Provider (VTSIP) is an entity who uses TS Information in the

same manner as a Customer and provides value-added information services to its Customers.

2. Network Architecture Requirements

2.1 Architecture of Oasis Nodes

a. Permit Use of Any OASIS Node Computers: TSIPS shall be permitted to use any computer systems as an OASIS

Node, so long as they meet the OASIS requirements.

b. Permit Use of Any Customer Computers: OASIS Nodes shall permit the use by Customers of any commonly

available computer systems, as long as they support the required communication links to the Internet.

c. Permit the Offering of Value-Added Services: TSIPs are required, upon request, to provide their Customers the

use of private network connections on a cost recovery basis. Additional services which are beyond the scope of the

minimum OASIS requirements are also permitted. When provided, these private connections and additional services

shall be offered on a fair and non-discriminatory basis to all Customers who might choose to use these services.

d. Permit Use of Existing Communications Facilities: In implementing the OASIS, the use of existing communications

facilities shall be permitted. The use of OASIS communication facilities for the exchange of information beyond that

required for open transmission access (e.g., transfer of system security or operations data between regional control

centers) shall also be permitted, provided that such use does not negatively impact the exchange of open transmission

access data and is consistent with the Standards of Conduct in Part 37.

e. Single or Multiple Providers per Node: An OASIS Node may support a single individual Primary Provider (plus

any Secondary Providers) or may support many Primary Providers.

2.2 Internet-Based OASIS Network

a. Internet Compatibility: All OASIS Nodes shall support the use of internet tools, internet directory services, and

internet communication protocols necessary to support the Information Access requirements stated in Section 4.

b. Connection through the Public Internet: Connection of OASIS Nodes to the public Internet is required so that

Users may access them through Internet links. This connection shall be made through a firewall to improve security.

c. Connection to a Private Internet Network: OASIS Nodes shall support private connections to any OASIS User

(User) who requests such a connection. The TSIP is permitted to charge the User, based on cost, for these connections.

The same internet tools shall be required for these private networks as are required for the public Internet. Private

connections must be provided to all users on a fair and nondiscriminatory basis.

d. Internet Communications Channel: The OASIS Nodes shall utilize a communication channel to the Internet which

is adequate to support the performance requirements given the number of Users subscribed to the Providers on the

Node (see section 5.3).

2.3 Communication Standards Required

a. Point-to-Point Protocol (PPP) and Internet Protocol Control Protocol (IPCP) (reference RFCs 1331 and 1332) shall

be supported for private internet network dial-up connections.

b. Serial Line Internet Protocol (SLIP) (reference RFC 1055) shall be supported for private internet network dialup connections.

c. Transport Control Protocol and Internet Protocol (TCP/IP) shall be the only protocol set used between OASIS

Nodes whenever they are directly interconnected, or between OASIS Nodes and Users using private leased line internet

network connections.

d. Hyper Text Transport Protocol (HTTP), Version 1.0 (RFC 1945), shall be supported by User’s web browsers

so they can use it to select information for viewing displays and for downloading and uploading filed electronically.

e. Internet Protocol Address: All OASIS Nodes are required to use an IP address registered with the Internet Network

Information Center (InterNIC), even if private connections are used.

2.4 Internet Tool Requirements

Support for the following specific internet tools is required, both for use over the public Internet as well as for

any private connections between Users and OASIS Nodes:

a. Hypertext Markup Language (HTML), at least Version 3.2 shall be used by supported by User’s browsers as

a standard tool for viewing information.

b. HTML Forms shall be provided by the TSIPs to allow Customers to enter information to the OASIS Node.

c. Domain Name Service (DNS) (ref. RFC 1034, 1035) shall be provided as a minimum by the TSIPs (or their

Internet Service Provider) for the resolution of IP addresses to allow Users to navigate easily between OASIS Nodes.

d. Simple Network Management Protocol (SNMP) is recommended but not required to provide tools for operating

and managing in network. If private interconnections between OASIS Nodes are established.
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38955

e. The Primary Provider shall support E-mail for exchanges with Customers, including the sending of attachments.

The protocols supported shall include, as a minimum, the Simple Messaging Transfer Protocol (SMTP), Post Office

Protocol (POP), and Multipurpose Internet Mail Extensions (MIME).

2.5 Navigation and Interconnectivity Between OASIS Nodes

a. World Wide Web Browsers: TSIPs shall permit Users to navigate using WWW browsers for accessing different

sets of TS Information from one Provider, or for getting to TS Information from different Providers on the same OASIS

Node. These navigation methods shall not favor User access to any Provider over another Provider, including Secondary

Providers.

b. Internet Interconnection across OASIS Nodes: Navigation tools shall not only support navigation within the TSIP’s

Node, but also across interconnected OASIS Nodes. This navigation capability across interconnected Nodes shall, as

a minimum, be possible through the public Internet.

3. Information Access Requirements

3.1 Registration and Login Requirements

a. Location of Providers: To provide Users with the information necessary to access the desired Provider, all Primary

Providers shall register their OASIS Node URL address with www.tsin.com. This URL address should include the unique

four letter acronym the Primary Provider will use as the PRIMARYlPROVIDERlCODE.

b. Initial User Registration: TSIPs shall require Users to register with a Primary Provider before they are permitted

to access the Provider’s TS Information. There must be a reference pointing to registration procedures on each Primary

Provider’s home page. Registration procedures may vary with the administrative requirements of each Primary provider.

c. Initial Access Privileges: Initial registration shall permit a User only the minimum Access Privileges. A User

and a Primary Provider shall mutually determine what access privilege the User is permitted. The TSIP shall set a

User’s Access Privilege as authorized by the Primary Provider.

d. User Login: After registration, Users shall be required to login every time they establish a dial-up connection.

If a direct, permanent connection has been established, Users shall be required to login initially or any time the connection

is lost. Use of alternative forms of login and authentication using certificates and public key standards is acceptable.

e. User Logout: Users shall be automatically logged out any time they are disconnected. Users may logout voluntarily.

3.2 Service Level Agreements

Service Level Agreements: It is recognized that Users will have different requirements for frequency of access, performance, etc., based on their unique business needs. To accommodate these differing requirements, TSIPs shall be required

to establish a ‘‘Service Level Agreement’’ with each User which specifies the terms and conditions for access to the

information posted by the Providers. The default Service Level Agreement shall be Internet access with the OASIS

Node meeting all minimum performance requirements.

3.3 Access to Information

a. Display: TSIPs shall format all TS Information in HTML format such that it may be viewed and read directly

by Users without requiring them to download it. This information shall be in clear English as much as possible,

with the definitions of any mnemonics or abbreviations available on-line. The minimum information that is to be

displayed is provided in the Templates in Section 4.3.

b. Read-Only Access to TS Information: For security reasons, Users shall have read-only access to the TS Information.

They shall not be permitted to enter any information except where explicitly allowed, such as HTML transaction request

forms or by the Templates in Section 4.3.

c. Downloading Capability: Users shall be able to download from an OASIS Node the TS Information in electronic

format as a file. This rules for formatting of this data are described in Section 4.2.

d. On-Line Data Entry on Forms: Customers shall be permitted to fill out on-line the HTML forms supplied by

the TSIPs, for requesting the purchase of services and for posting of products for sale (by Customers who are resellers).

Customers shall also be permitted to fill-out and post Want-Ads.

e. Uploading Capability: Customers shall be able to upload to OASIS Nodes the filled-out forms. TSIPs shall ensure

that these uploaded forms are handled identically to forms filled out on-line. TSIPs shall provide forms that support

the HTTP input of Comma Separated Variable (CSV) records. This capability shall permit a Customer to upload CSV

records using standard Web browsers or additional client software (such as fetchlhttp) to specify the location of the

CSV records stored on the Customer’s hard disk.

f. Selection of TS Information: Users shall be able to dynamically select the TS Information they want to view

and/or download. This selection shall be, as a minimum, through navigation to text displays, the use of pull-down

menus to select information for display, data entry into forms for initiating queries, and the selection of files to download

via menus.

3.4 Provider Updating Requirements

The following are the Provider update requirements:

a. Provider Posting of TS Information: Each Provider (including Secondary Providers and Value-Added Providers)

shall be responsible for writing (posting) and updating TS Information on their OASIS Node. No User shall be permitted

to modify a Provider’s Information.

b. Info.HTM: Each Provider shall provide general information on how to use their node and describe all special

aspects, such as line losses, congestion charges and assistance. The address for the directory of this information shall

be INFO.HTM, an HTML web page, linked to the Provider’s registered URL ADDRESS.

c. OASIS Node Space for Secondary Provider: To permit Users to readily find TS Information for the transmission

systems that they are interested in, TSIPs shall provide database space on their OASIS Node for all Secondary Providers
38956 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

who have purchased, and who request to resell, transmission access rights for the power systems of the primary Providers

supported by that Nod.

d. Secondary Provider Posting to Primary Provider Node: The Secondary providers shall post the relevant TS Information on the OASIS Node associated with each Primary Provider from whom the transmission access rights were originally

purchased.

e. Secondary Provider Posting Capabilities: The TSIPs shall ensure that the Secondary Providers shall be able to

post their TS Information to the appropriate OASIS Nodes using the same tools and capabilities as the Customers,

meet the same performance criteria as the Primary Providers, and allow users to view these postings on the same

display page, using the same tables, as similar capacity being sold by the Primary Providers.

f. Free-Form Posting of non-TS Information: The TSIP shall ensure that non-TS Information, such as Want-Ads,

may be posted by providers and Customers, and that this information is easily accessible by all Users. The TSIP

shall be allowed to limit the volume and/or to charge for the posting of non-TS Information.

g. Time Stamps: All TS Information shall be associated with a time stamp to show when it was posted to the

OASIS Node.

h. Transaction Tracking by an Assignment Reference Number: All requests for purchase of transmission or ancillary

services will be marked by a unique accounting number, called an assignment reference.

i. Time-Stamped OASIS Audit Log: All posting of TS Information, all updating of TS Information, all User logins

and disconnects, all User download requests, all Service Requests, and all other transactions shall be time stamped

and stored in an OASIS Audit Log. This OASIS Audit Log shall be the official record of interactions, and shall be

maintained on-line for download for at least 90 days. Changes in the values of posted Capacity (Available Transfer

Capability) must be stored in the on-line Audit Log for 20 days. Audit records must be maintained for 3 years offline and available in electronic form within seven days of a Customer request.

j. Studies: A summary description with dates, and programs used of all transmission studies used to prepare data

for the Primary Provider’s ATC and TTC calculation will be provided along with information as to how to obtain

the study data and results.

3.5 Access to Changed Information

a. General Message & Log: TSIPs shall post a general message and log that may be read by Users. The message

shall state that the Provider has updated some information, and shall contain (or point to) a reverse chronological

log of those changes. This log may be the same as the Audit Log. The User may use the manual capability to see

the message.

b. TSIP Notification Design Responsibilities: The TSIP shall avoid a design that could cause serious performance

problems by necessitating frequent requests for information from many Users.

3.6 User Interaction with an OASIS Node

There are three basic types of User interactions which must be supported by the OASIS Node. These interactions

are defined in Section 4.3.

a. Query/Response: The simplest level of interactions is the query of posted information and the corresponding

response. The User may determine the scope of the information queried by specifying values, through an HTML form,

a URL string, or an uploaded file, using Query Variables and their associated input values as defined with each Template

in Section 4.3. The response will be either an HTML display or a record oriented file, depending on the output

format that the User requests.

The TSIP may establish procedures to restrict the size of the response, if an overly broad query could result in

a response which degrades the overall performance of the OASIS Node for their Users.

b. Purchase Request: The second type of Customer interaction is the submittal of a request to purchase a service.

The Customer completes an input form, a URL string or uploads a file and submits it to the OASIS Node. The uploaded

file can either be a series of query variables or a record oriented file.

The request is processed by the Seller of the service, possibly off-line from the OASIS Node, and the status is

updated accordingly.

If a purchase request is approved by the Seller, then it must be again conformed by the Customer. Once the

Customer confirms an approved purchase, a reservation for those services is considered to exist, unless later the reservation

is reassigned, displaced, or annulled.

c. Upload and Modify Postings: Customers who wish to resell their rights may upload a form, create the appropriate

URL or upload a file to post services for sale. A similar process applies to eligible Third Party Sellers of ancillary

services. The products are posted by the TSIP. The seller may monitor the status of the services by requesting status

information. Similarly the Seller may modify its posted transmission services by submitting a service modification request

through a form, a URL query, or by uploading a file.

4. Interface Requirements

4.1 Information Model Concepts

a. ASCII-Based OASIS Templates: For providing information to Users, TSIPs shall use the specified OASIS Templates.

These Templates define the information which must be presented to Users, both in the form of graphical displays

and as downloaded files. Users shall be able to request Template information using query-response data flows. The

OASIS Templates are described in section 4.3. The Data Element Dictionary, which defines the data elements in the

OASIS Templates, is provided in Appendix A.

Data elements must be used in the exact sequence and number as shown in the Templates when file uploads

and downloads are used. Although the contents of the graphical displays are precisely defined as the same information

as in the Templates, the actual graphical display formats of the TS information are beyond the scope of the OASIS
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38957

requirements. Due to the nature of graphical displays, there may be more than one graphical display used to convey

the information in a single Template.

b. ASCII-Based OASIS File Structures: For uploading requests from and downloading information to Users, TSIPs

shall use specific file structures that are defined for OASIS Template information (see section 4.2). These file structures

are based on the use of headers which contain the Query Variable information, including the name of the OASIS

Template. These headers thus determine the contents and the format of the data that follows. Although headers may

not be essential if file transfers contain the exact sequence and number of data elements as the Templates, this feature

is being preserved for possible future use when additional flexibility may be allowed.

4.2 OASIS Node Conventions and Structures

4.2.1 OASIS Node Naming Requirements

The following naming conventions shall be used to locate information posted on OASIS. OASIS naming conventions

shall conform to standard URL structures.

4.2.1.1 OASIS Node Names

In order to provide a consistent method for locating an OASIS Node, the standard Internet naming convention

shall be used. All OASIS Node names shall be unique. Each Primary Provider OASIS Node name and home directory

shall be registered with the master OASIS directory site at http://www.tsin.com. OASIS Node names shall be stored

in an Internet DNS name directory.

4.2.1.2 OASIS Node and Primary Provider Home Directory

The home directory name on an OASIS Node shall be ‘‘OASIS’’ to identify that the directory is related to the

OASIS. The directory of each Primary Provider shall be listed under the ‘‘OASIS’’ directory:

http://(OASIS Node name)/OASIS/(PRIMARYlPROVIDERlCODE)

Where:

(OASIS Node name) is the World Wide Web URL address of the OASIS Information Provider.

(PRIMARYlPROVIDERlCODE) is the 4 character acronym of the primary provider.

PRIMARYlPROVIDERlCODEs shall be registered with the master OASIS directory site at http://www.tsin.com.

A pointer to user registration information shall be located on the Primary Provider’s home page.

4.2.1.3 CGI Script Names

Common Gateway Interface (CGI) scripts shall be located in the directory ‘‘data’’ as follows:

http://(OASIS Node name)/OASIS/(PRIMARYlPROVIDERlCODE/data/(cgi script name)?(query variables)

Where:

(cgi script name) is the OASIS Template name (see Section 4.3). Other cgi scripts may be defined as required to

implement the HTML interface to the documented templates. (query variables) is a list of query variables with their

settings formatted as defined by the HTTP protocol (i.e., URL encoded separated by ampersands).

Example:

To request the hourly schedule Template at Primary Provider WXYZ Co.

http://www.wxy.com/oasis/wxyz/data/schedule ?templ=schedule& ver=1.2&fmt=data & stime=19960412040000PD

&sptime=19960412100000PD& pprov=wxyz

4.2.2 Data Element Dictionary

The following are the requirements for the Data Element Dictionary:

a. Definition of OASIS Information Elements: All OASIS Information data elements shall be defined in the Data

Element Dictionary which will be stored in the OASIS Node directory:

http://(OASISNode Name)/OASIS/(PRIMARYlPROVIDERlCODE)/ (datadic.html datadict.txt)

Where:

datadic.html is the HTML version of the data element dictionary

datadic.txt is the ASCII text version of the data element dictionary

The Data Element Dictionary is defined in Appendix A.

b. Provider-specific Data Element Values: The valid values that certain OASIS Information data elements may take

on, such as PATHlNAME, etc., are unique to a Primary Provider. Names which must be uniquely identified by Primary

Provider shall be listed on-line on the OASIS Node via the LIST Template (see Section 4.3.5). In posting OASIS information

associated with data elements which are not free-form text, TSIPs shall use only the accepted data element values

listed in the Data Element Dictionary and/or those values posted in the LIST of provider specific names provided

on the OASIS.

4.2.3 OASIS Template Constructs

4.2.3.1 Template Construction

Section 4.3 lists the set of OASIS Templates that shall be supported by all OASIS nodes. These OASIS Templates

are intended to be used precisely as shown for the transfer of data to/from OASIS, and identify, by Data Elements

names, the information to be transferred. The construction of the OASIS Templates shall follow the rules described

below:

a. Unique OASIS Template Name: Each type of OASIS Template shall be identified with a unique name which

shall be displayed to the User whenever the OASIS Template is accessed.

b. Transfer Protocol: OASIS Templates are transferred using the HTTP protocol. Templates shall support both the

‘‘GET’’ and ‘‘POST’’ methods for transferring ‘‘query string’’ name/value pairs, as well as the OASIS specific ‘‘comma
38958 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

separated value’’ (CSV) format for posting and retrieval of information from OASIS. HTML screens and forms shall

be implemented for each OASIS Template.

c. Source Information: Each OASIS Template shall identify the source of its information by including or linking

to the name of the Primary Provider, the Secondary Provider, or the Customer who provided the information.

d. Time Of Last Update: Each OASIS Template shall include a time indicating when it was created or whenever

the value of any Data Element was changed.

e. Data Elements: OASIS Templates shall define the elementary Data Element Dictionary names for the data values

to be transferred or displayed for that Template.

f. Documentation: OASIS Information shall be in non-cryptic English, with all mnemonics defined in the Data Element

Dictionary or a glossary of terms. TSIPs shall provide on-line descriptions and help screens to assist Users understanding

the displayed information. Documentation of all formats, contents, and mnemonics shall be available both as displays

and as files which can be downloaded electronically. In order to meet the ‘‘User-Friendly’’ goal and permit the flexibility

of the OASIS to expand to meet new requirements, the OASIS Templates shall be as self-descriptive as possible.

4.2.3.2 Template Categories

OASIS Templates are grouped into the following two major categories:

a. Query/Response: These Templates are used to query and display information posted on OASIS. Each query/

response Template accepts a set of user specified Query Variables and returns the appropriate information from data

posted on OASIS based on those query variables. The valid Query Variables and information to be returned in response

are identified by Data Element in Section 4.3.

b. Input/Response: These Templates are used to upload/input information on OASIS. The required input information

and information to be returned in response are identified by Data Element in Section 4.3, Template Descriptions.

4.2.3.3 Template HTML Screens

Though the exact form and content of the HTML screens and forms associated with the OASIS Templates are

not dictated by this document, the following guidelines shall be adhered to for all HTML screens and forms implemented

on OASIS:

a. Data Element Headings: Data displayed in an HTML screen/form shall be labeled such that the associated data

value(s) is(are) easily and readily identifiable as being associated with a particular OASIS Template Data Element.

HTML ‘‘Hot-Links’’ or other pointer mechanisms may be provided for Data Element headings in OASIS Templates

which permit the User to access documentation describing the meaning, type, and format of the associated data.

b. Display Limitations: HTML screens and forms shall be implemented in such a way to allow the display of

all data specified for each OASIS Template. This may take the form of ‘‘wrapping’’ of lines of information on the

screen, the use of horizontal and/or vertical scrolling, or the use of ‘‘Hot-Links’’ or other pointer mechanisms. There

is not necessarily a one-to-one relationship between OASIS implemented HTML screens and their associated Template.

However, all Template data elements shall be viewable through one or more HTML screens.

c. Template Navigation: HTML ‘‘Hot-Links’’ or other pointer mechanisms may be provided to assist the navigation

between screens/forms associated with related OASIS Templates.

4.2.4 Query/Response Template Requirements

Retrieval of information posted on OASIS is supported by the Query/Response Templates. The ‘‘query’’ identifies

the OASIS Template and optionally supplies additional Data Elements which may be used to select specific information

to be returned in the ‘‘response’’.

4.2.4.1 Query Requirements

Query information is transferred to OASIS using the HTTP protocol as a string of Query Variables in the form

of name/value pairs. Query Variable name/value pairs are specified as a collection of encoded strings (e.g., blank characters

replaced by plus (+) character, etc.) in the form of name=value, with each name/value pair separated by ampersands

(&) (see section 4.2.6). OASIS shall support the following methods for Users to input Query information:

a. HTML: HTML FORM input and/or hypertext links shall be provided to allow Users to specify OASIS Template

Query Variables. This will be the easiest way to obtain information and should be the choice of most casual Users

and for simple reasons. The exact nature and form of these HTML screens are not specified, and may differ between

OASIS nodes.

b. GET Method: The HTTP GET method for specifying query information appended to a standard OASIS URL

shall be supported. Using this method, the name=value formatted Query Variables preceded by a question mark (?)

are appended to the URL. Each ‘‘name’’ in a name/value pair corresponds to a Data Element name associated with

that Template. OASIS shall support the specification of all Data Elements associated with a Template by both their

full name and alias as defined in the Data Dictionary. The ‘‘value’’ in a name/value pair represents the value to

be associated with the Data Element being specified in the appropriate format as defined in the Data Dictionary and

encoded according to the HTTP protocol.

c. POST Method: The HTTP POST method for specifying query information in the message body shall be supported.

Using this method, the name=value formatted Query Variables shall be transferred to OASIS using the ‘‘Content-length:’’

HTTP header to define the length in bytes of the encoded query string and the ‘‘Content-type: application/x-wwwform-urlencoded’’ HTTP header to identify the data type included in the message body. Each ‘‘name’’ in a name/

value pair corresponds to a Data Element name associated with that Template. OASIS shall support the specification

of all Data Elements associated with a Template by both their full name and alias as defined in the Data Dictionary.

The ‘‘value’’ in a name/value pair represents the value to be associated with the Data Element being specified in

the appropriate format as defined in the Data Dictionary and encoded according to the HTTP protocol.

Using queries using any of the above methods are supported directly by the User’s web browser software. More

sophisticated data transfer mechanisms, such as the automated querying of information based on Query Variable strings
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38959

contained in a User data file (i.e., ‘‘uploading a file containing a URL string), require appropriate software (e.g.,

‘‘fetchlhttp’’) running on the User’s computer system to effect the data transfer.

4.2.4.2 Response Requirements

In response to a validly formatted Query for each Query/Response OASIS Template, the OASIS shall return the

requested information in one of two forms based on the User specified OUTPUTlFORMAT Query Variable:

a. HTML: If the User requests the response to have the format of ‘‘HTML’’ (OUTPUTlFORMAT=HTML) then the

response from the OASIS shall be a web page using the HTML format. This shall be the default for all Query/Response

Templates.

b. CSV Format: Comma Separated Value (CSV) format (OUTPUTlFORMAT=DATA) returns the requested information

in the body of the HTTP response message. The ‘‘Content-length:’’ HTTP header shall define the length in bytes of

the response, and the ‘‘Content-type: text/x-oasis-csv’’ HTTP header shall be used to identify the data type included

in the message body (see CSV File Format).’

4.2.5 Input/Response Template Requirements

The posting of information on OASIS, including reservations for transmission/ancillary service, services for sale

on the secondary market, etc., is supported by the Input/Response Templates. The ‘‘input’’ identifies the required data

associated with an OASIS Template to be posted on OASIS, and the ‘‘response’’ specifies the information returned

to the User.

4.2.5.1 Input Requirements

Input information is transferred to OASIS using the HTTP protocol as either a string of Query Variables in the

form of name/value pairs, or as a Comma Separated Value (CSV) message. Query Variable name/value pairs are specified

as a collection of encoded strings (e.g., blank characters replaced by plus (+) character, etc.) in the form of name=value,

with each name/value pair separated by ampersands (&). CSV formatted messages are specified in the body of an

HTTP message as a series of data records preceded by a fixed set of header records (see section 4.2.7).

OASIS shall support the following methods for Users to transfer Input data:

a. HTML: HTML FORM input shall be provided to allow Users to specify the necessary Input data associated

with each Input/Response OASIS Template. This may be in the form of fill in blanks, buttons, pull-down selections,

etc., and may use either the GET or POST methods. The exact nature and form of these HTML screens are not specified,

and may differ between OASIS nodes.

b. GET Method: The HTTP GET method for specifying Input information in the form of a query string appended

to a standard OASIS URL shall be supported. Using this method, the name=value formatted Query Variables preceded

by a question mark (?) are appended to the URL. Each ‘‘name’’ in a name/value pair corresponds to a Data Element

name associated with that Template. OASIS shall support the specification of all Data Elements associated with a

Template by both their full name and alias as defined in the Data Dictionary. The ‘‘value’’ in a name/value pair

represents the value to be associated with the Data Element being specified in the appropriate format as defined in

the Data Dictionary and encoded according to the HTTP protocol.

c. POST Method: The HTTP POST method for specifying Input information in the form of a query string in the

message body shall be supported. Using this method, the name=value formatted Query Variables shall be transferred

to OASIS using the ‘‘Content-length: ‘‘HTTP header to define the length in bytes of the encoded query string and

the ‘‘Content-type: application/x-www-form-urlencoded’’ HTTP header to identify the data type included in the message

body. Each ‘‘name’’ in a name/value pair corresponds to a Data Element name associated with that Template. OASIS

shall support the specification of all Data Elements associated with a Template by both their full name and alias

as defined in the Data Dictionary. The ‘‘value’’ in a name/value pair represents the value to be associated with the

Data Element being specified in the appropriate format as defined in the Data Dictionary and encoded according to

the HTTP protocol.

d. CSV Format: Comma Separated Value (CSV) formatted Input information transferred in the body of a User’s

HTTP message shall be supported. The ‘‘Content-length:’’ HTTP header shall define the length in bytes of the Input,

and the ‘‘Content-type: text/x-oasis-csv’’ HTTP header shall be used to identify the data type included in the message

body.

4.2.5.2 Response to Input

In response to a validly formatted Input for each Input/Response OASIS Template, the OASIS shall return an indication

as to the success/failure of the requested action. The OASIS shall respond to the Input in one of two forms, based

on the OUTPUT—FORMAT, which was input by a User either as a Query Variable or in a CSV format Header Record:

a. HTML: If the User requests the response to have the format of ‘‘HTML’’ (OUTPUTlFORMAT=HTML) then the

response from the OASIS shall be a web page using the HTML format. This shall be the default for all Input/Response

Templates invoked using either the FORM, GET or POST methods of input.

b. CSV Format: Comma Separated Value (CSV) format (OUTPUTlFORMAT=DATA) returns the response information

in the body of the HTTP response message. The ‘‘Content-length:’’ HTTP header shall define the length in bytes of

the response, and the ‘‘Content-type: text/x-oasis-csv’’ HTTP header shall be used to identify the data type included

in the message body. This shall be the default for all Input/Response Templates invoked using the CSV Format methods

of input.

4.2.6 Query Variables

4.2.6.1 General

Both Query/Response and Input/Response OASIS Templates shall support the specification of a query string consisting

of Query Variables formatted as name/value pairs. OASIS shall support the specification of Data Element names (‘‘name’’
38960 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

portion of name=value pair) in both the full name and alias forms defined in the Data Dictionary. OASIS shall support

the specification of Query Variables from the User using either the HTTP GET or POST methods. On input, Data

Element names and associated values shall be accepted and processed without regard to case. On output, Data Element

names and associated values may not necessarily retain the input case, and could be returned in either upper or

lower case.

4.2.6.2 Standard Header Query Variables

The following standard Query Variable Data Elements shall be supported for all OASIS Templates and must be

entered for each Query by a User:

VERSION

TEMPLATE

OUTPUTlFORMAT

PRIMARYlPROVIDERlCODE

PRIMARYlPROVIDERlDUNS

RETURNlTZ

Since these header Query Variables must be supported for all Templates, they are not listed explicitly in the Template

descriptions in Section 4.3

All standard header Query Variables with appropriate values must be entered by the User.

4.2.6.3 Responses to Queries

Responses to Queries will include the following information as a minimum:

TIMElSTAMP

VERSION

TEMPLATE

OUTPUTlFORMAT

PRIMARYlPROVIDERlCODE

PRIMARYlPROVIDERlDUNS

RETURNlTZ

The additional information shall include:

a. The requested information as defined by the Template indicated in the Query

b. For CSV downloads, the additional header Data Elements required (see section 4.2.7.3)

4.2.6.4 Multiple Instances

Certain Query Variables may be repeated in a given Query/Response OASIS Template query string. Where such

multiple instances are documented in the Template definitions using an asterix (*) after the query variable. When

more than one instance of the Query Variable is specified in the query string, OASIS shall recognize such multiple

instances by either the Data Element’s full name or alias suffixed with sequential numeric qualifiers starting with

the number 1, (e.g., PATHlNAME1=abc&PATHlNAME2=xyz, or PATH1=abc&PATH2=xyz). At least 4 multiple instances

will be permitted for each query variable marked with an asterix (*).

4.2.6.5. Logical Operations

OASIS shall use the following logical operations when processing Query Variables for Query/Response OASIS Templates. All Query Variables, with the exception of multiple instances of the same Query Variable Data Element, shall

be operated on to return information based on the logical-AND of those Query Variables. For example, the query string

‘‘* * *SELLERlCODE=abc&PATH=xyz* * *’’ should return information associated with only those records that are on

transmission path ‘‘xyz’’ AND associated with transmission provider ‘‘abc.’’ Multiple instances of the Query Variable

shall be operated on as logical-OR. For example, ‘‘* * *SELLERlCODE=abc&PATH1=xyz&PATH2=opq* * *’’ should

return information associated with transmission provider ‘‘abc’’ AND either transmission path ‘‘xyz’’ OR transmission

path ‘‘opq’’. Some logical operations may exclude all possibilities, such that the responses may not contain any data.

4.2.6.6 Handling of Time Data Elements

In cases where a single query variable is provided to select information associated with a single template data

element that represents a point in time (e.g., TIMElOFlLASTlUPDATE), OASIS shall return to the user all requested

information whose associated data element time value (e.g. TIMElOFlLASTlUPDATE) is equal to or later than the

value specified by the query variable. In this case the stop time is implicitly ‘‘now’’.

A pair of query variables (e.g. STARTlTIMElQUEUED and STOPlTIMElQUEUED) that represents the start and

stop of a time interval but is associated with one single template data element (e.g. TIMElQUEUED) shall be handled

by OASIS to return to the User all requested information whose associated data element time value falls within the

specified time interval.

A pair of query variables (e.g. STARTlTIME and STOPlTIME query variables) that represents the start and stop

of one time interval but is associated with another pair of template data elements (e.g. STARTlTIME and STOPlTIME

of a service offering) that represents a second time interval, shall be handed by OASIS to return to the User all

requested information whose associated data element time interval overlaps any portion of the specified time interval.

Specifically, the STARTlTIME query variable, and the STOPlTIME query variable selects all information whose

STARTlTIME data element value is earlier than the STOPlTIME query variable. For example:

The transoffering template query string STARTlTIME 970101000000ES&STOPlTIME 970201000000ES’’ shall select from

the OASIS database all associated offerings whose start/stop times overlap any portion of the time form 00:00 January

1, 1997, to 00:00 February 1, 1997. This would include offerings that (1) started prior to Jan. 1. stopped any time

on or after Jan. 1, and (2) started on or after Jan. 1 but before Feb. 1
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38961

For changes to and from daylight savings time, either Universal Time or the correct time and zone must be used,

based on whether daylight savings time is in effect.

All time values shall be checked upon input to ensure their validity with respect to date, time, time zone, and

daylight savings time.

4.2.6.7 Default Values

Query Variable that are not specified by the User may take on default values as appropriate for that Query Variable

at the discretion of the OASIS TSIP.

4.2.6.8 Limitations on Queries

OASIS TSIP may establish validation procedures and/or default values for Query Variables to restrict the size and/

or performance impact of overly broad queries.

4.2.7 CSV Format

4.2.7.1 General Record Format

OASIS Users shall be able to upload information associated with Input/Response OASIS Templates and download

information associated with all OASIS Templates using a standardized Comma Separated Value (CSV) format. CSV

formatted data is transferred to/from OASIS as part of the body of an HTTP message using the ‘‘Content-length:’’ HTTP

header to define the length in bytes of the message body, and the ‘‘Content-type: text/x-oasis-csv’’ HTTP header to

identify the data type associated with the message body. CSV formatted data consists of a fixed set of header records

followed by a variable number of data records. Each record shall be separated by a carriage return plus line feed

(denoted by the symbol ↵ in all examples). The fields within a record shall be delimited by commas (,). All data

within a CSV formatted message shall use printable ASCII characters with no other special embedded codes, with

the exception of the special encoding requirements associated with text fields.

4.2.7.2 Input Header Records

The following standard header records are required for the uploading of Input data for all Input/Response OASIS

Templates:

VERSION=nn.nTM

TEMPLATE=aaaaaaaaaaTM

OUTPUTlFORMAT=[DATA]TM

PRIMARYlPROVIDERlCODE=aaaaTM

PRIMARYlPROVIDERlDUNS=nnnnnnnnnTM

RETURNlTZ=aaTM

DATAlROWS=nnnTM

COLUMNlHEADERS=[Template data element names separated by commas]TM

The format of the value associated with each of the Input header record Data Elements are dictated by the Data

Dictionary.

The value associated with the DATAlROWS Data Element shall define the total number of data records that follow

in the message after the COLUMNlHEADERS record.

The COLUMNlHEADERS record defines, by Data Element name, the data associated with each comma separated

column contained in each subsequent data record (row). On Input, either the Data Element’s full name or alias listed

in the Data Dictionary may be specified.

4.2.7.3 Response Header Records

When explicitly specified using the OUTPUTlFORMAT=DATA Query Variable or implied by the Input of a CSV

format message, the OASIS shall respond with the following standard response header records for all OASIS Templates:

REQUESTlSTATUS=nnnTM

ERRORlMESSAGE=aaa...TM

TIMElSTAMP=yyyymmddhhmmsstzTM

VERSION=nn.nTM

TEMPLATE=aaaaaaaaaaTM

OUTPUTlFORMAT=DATATM

PRIMARYlPROVIDERlCODE=aaaaTM

PRIMARYlPROVIDERlDUNS=nnnnnnnnnTM

RETURNlTZ=tzTM

DATAlROWS=nnnTM

COLUMNlHEADERS=[Template data element names separated by commas]TM

The format of the value associated with each of the Response header record Data Elements are dictated by the

Data Dictionary.

The value associated with the DATAlROWS Data Element shall define the total number of data records returned

in the message following the COLUMNlHEADERS header record.

The COLUMNlHEADERS record defines, by Data Element name, the data associated with each comma-separated

column contained in each subsequent data record (row). In all OASIS responses, the Data Element’s full name shall

be listed in the COLUMNlHEADERS record. The order of the column headings shall be the same as shown in the

Templates for URL uploads and downloads. For graphical displays, the Provider may define the order that the Data

Element names are shown.

4.2.7.4 Data Records

Data Records immediately follow the standard Input or Response header records. With the exception of data records

grouped together as a single ‘‘logical record’’ through the use of Continuation Records, each data record in a CSV
38962 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

formatted Input message represents a single, complete execution of the associated OASIS Template. That is, sending

five CSV formatted Input messages for a given Template to the same PRIMARYlPROVIDERlCODE with as single

data record per message shall be handled in exactly the same fashion as sending a single CVS formatted Input message

for the same Template and PRIMARYlPROVIDERlCODE which contains five data records.

Each field (column) within each data record defines the value to be associated with the corresponding Data Element

defined in the COLUMNlHEADERS record. The number of Data Records in the message is defined by the DATAlROWS

header record. The data values associated with each column Data Element are interpreted based on the Data Element

type as defined in the Data Dictionary:

a. Numeric Data Elements: All numeric Data Elements shall be represented by an ASCII string of numeric digits

in base ten, plus the decimal point.

b. Text Data Elements: Alphabetic and alphanumeric data elements shall be represented as ASCII strings and encoded

using the following rules:

• Text strings that do not contain commas (,) or double quotes (’’) shall be accepted both with and without being

enclosed by double quotes.

• Text fields with commas (,) or double quotes (’’) must be enclosed with double quotes. In addition double quotes

within a text field shall be indicated by two double quotes (‘‘ ’’ ).

• The Data Element field length specified in Data Dictionary does not include the additional double quotes necessary

to encode text data.

a. Null Data Elements: Null Data Elements shall be represented by two consecutive commas (,,) corresponding to

the leading and trailing (if appropriate) Data Element comma separators. Null text strings may optionally be represented

by two consecutive double quote characters within the leading and trailing comma separators (i.e., ..., ‘‘ ’’, ...).

4.2.7.5 Continuation Records

Continuation records shall be used to indicate that the information in multiple rows (records) is part of one logical

record. Continuation records will be indicated through the use of a column header called CONTINUATIONlFLAG.

This column header is either the first column (if in a response to a query) or second column (if in a response to

an input) in all Templates permitting continuation records. The first record shall contain a ‘‘N’’ in the CONTINUATIONlFLAG column and each following record which is part of a continuation record shall contain a ‘‘Y’’ in this

column, thus associating the information in that record with the information in the previous record. An ‘‘N’’ shall

indicate that the record is not a continuation record. Any values corresponding to COLUMNlHEADERs other than

those explicitly allowed for a particular Template shall be ignored. However commas must be included to properly

align the fields.

4.2.7.6 Error Handling in CSV-Formatted Responses

Validity of each record in the CVS-formatted Response to a Template Input shall be indicated through the use

of RECORDlSTATUS and ERRORlMESSAGE Data Elements which are included in each data record (row) of the

Response.

• If no error was encountered in an Input data record, the RECORDlSTATUS Data Element in the corresponding

Response record shall be returned with a value of 200 (success), and the ERRORlMESSAGE shall be blank.

• If any error is detected in processing an Input data record, it shall be indicated by a RECORDlSTATUS Data

Element value other than 200. The ERRORlMESSAGE shall be set to an appropriate text message to indicate the

source of the error in that data record.

The overall validity of each Template Query or Input shall be indicated in the CSV-formatted Response via the

two REQUESTlSTATUS and ERRORlMESSAGE header records (see section 4.2.7.3):

• If no errors were encountered in processing the User’s Input data records, the REQUESTlSTATUS shall be returned

with the value of 200 (success), and the ERRORlMESSAGE shall be blank.

• If any errors were detected in the Template Input data records, the REQUESTlSTATUS value shall any value

other than 200, and the ERRORlMESSAGE shall be set to an appropriate text message to indicate the source of

the error.

The OASIS node shall validate all Input records before returning a Response to the User. All valid records shall

be processed by the node, while invalid records shall be identified as erroneous through he use of RECORDlSTATUS

and ERRORlMESSAGE. The User must correct the invalid fields and resubmit only those records which were invalid.If

an error is encountered in a record which is part of a set of Continuation records, then all records belonging to

that set must be resubmitted.

4.2.8 Registration Information

4.2.8.1 General

As specified in the Information Access Requirements, OASIS Nodes shall provide a mechanism to register Users

of the OASIS with a Provider. For all levels of access to OASIS information beyond simple read-only access, OASIS

node shall provide a mechanism to identify Users of the OASIS at least to the level of their respective Companies.

Both Company and User registration information shall be maintained by the OASIS node.

4.2.8.2 Company Information

OASIS Templates require that certain Company registration information be maintained. As an extension of the Company

registration information of the host, domain and port identifiers for dynamic notification of changes in the Customer’s

purchase requests, a field should be added to the Company’s registration information that would define/identify how

notification would be delivered to that Company should a transmission or ancillary purchase request be directed to

that Company as a Seller of a transmission or ancillary service. The pertinent information would be either a full
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38963

HTTP protocol URL defining the protocol, host name, port, path, resource, etc. information or a ‘‘mailto:’’ URL with

the appropriate mailbox address string. On receipt of any purchase request directed to that Company as SELLER via

either the ‘‘transrequest’’ or ‘‘ancrequest’’ templates, or on submission of any change in request STATUS to the Company

as SELLER via either the ‘‘transcust’’ or ‘‘anccust’’ templates, a notification message formatted as documented for the

delivery of notification to the Customer, shall be formatted and directed to the Seller. At a minimum, OASIS shall

maintain the following information for each Company.

a. Company Code: 4 character code for primary transmission providers; 6 character code for eligible customers

in accordance with NERC Tagging Information System (TIS) requirements shall be maintained for each Company.

b. Default Contact: Unless specified for each individual user affiliated with the Company, default contact information

consisting of a phone number, fax number, and e-mail address shall be maintained for each Company.

c. Provider Affiliation: Each eligible Customer shall be obligated to identify to the OASIS TSIP any affiliation with

a Transmission Provider whose ‘‘home page’’ is on that OASIS node.

d. Notification URL: For Companies using the URL notification mechanism for delivery of messages on each change

of ancillary/transmission reservation STATUS, each Company shall provide the IP host name and port number to be

used in delivering notification messages. OASIS nodes shall have the right to refuse support for notification to any

IP posts other than port 80.

4.2.8.3 User Information

With the exception of ‘‘read-only’’ (visitor) access, OASIS nodes shall as a minimum provide a mechanism to identify

Users of the node with at least their Company. However, OASIS nodes and Providers shall have the right to require

full User identification even for visitor accounts.

To support the required OASIS Template Data Elements, OASIS nodes shall maintain the following information

for each registered User:

• Company

• Name

• Phone

• Fax

• E-mail

In the event no additional User identification/registration information is maintained by the OASIS, all Template

Data Elements referring to ‘‘company, name, phone, fax, e-mail’’ for either Customers or Sellers shall default to the

Contact Information maintained for that User’s Company.

4.2.9 Representation of Time

4.2.9.1 General

It is critical that all Users of OASIS have a clear and unambiguous representation of time associated with all

information transferred to/from OASIS. For this reason, all Data Elements associated with time in OASIS shall represent

‘‘wall clock’’ times, which are NOT to be confused with other common industry conventions such as ‘‘hour ending.’’

For the convenience of the User community, OASIS nodes shall be allowed to accept the input and display of ‘‘time’’

in any acceptable form provided such non-standard representations are CLEARLY labeled on the associated HTML

screens. Alternate representations of time in CSV formatted messages shall not be allowed.

The following rules shall be implemented in OASIS for the representation of time on User entries (Query and

Input) and output (Response) Templates.

4.2.9.2 Input Time

All time related Data Elements associated with either the Input or Query of Input/Response or Query/Response

OASIS Templates shall be validated according to the following rules. If the time zone associated with a time Data

Element is associated with either Universal Time (UT) or a ‘‘standard’’ time zone (e.g., ES, CS, etc.), OASIS shall

accept and apply a fixed hour offset from Universal Time year-round. If the time zone associated with a time Data

Element is specified with a ‘‘daylight savings’’ time zone (e.g., ED, CD, etc.), OASIS shall verify that daylight savings

time is in effect for the date/time specified.

If daylight savings time (as specified by the time from 2:00 a.m. on the first Sunday of April through 2:00 a.m.

on the last Sunday of October) is not in effect, the Users input shall be rejected with an error response. If daylight

savings time is in effect, the Users input shall be accepted and the appropriate hours offset from Universal Time

shall be applied by OASIS for conversion to all other time zones. The input of start/stop times for transactions spanning

the crossover day between standard and daylight (and vice versa) times must be made either entirely in standard

time (valid year-round), or in two different time zones (xS/xD or xD/xS) for the start and stop times, depending on

the time of year.

4.2.9.3 Output (Response) Time

The OASIS shall return all time Data Elements in the response to Input/Response or Query/Response OASIS Templates

based on either the User specified RETURNlTZ header Query Variable or an appropriate OASIS specific default. OASIS

shall interpret RETURNlTZ to specify:

a. The base time zone for conversion of all time Data Elements (e.g. Eastern, Pacific, etc.).

b. Whether daylight savings time is recognized. For example, a RETURNlTZ=ES would return all time Data Elements

in Eastern Standard Time year-round. However, a RETURNlTZ=ED would direct OASIS to return all time Data Elements

in Eastern Standard Time (ES) when daylight savings time is not in effect, and then return all time Data Elements

in Eastern Daylight Time (ED) when daylight time is in effect.

4.2.10 Transaction Process

4.2.10.1 Purchase Transactions

Customers shall purchase services from the Seller using the following steps (see Exhibit 4–1):
38964 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

a. The Templates (transrequest and ancrequest) shall be used by a Customer to enter a request for specific transmission

services from a specific Seller. The Customer may enter a BIDlPRICE which is different from the OFFERlPRICE

in order to try to negotiate a lower price. The OASIS sets the initial STATUS of the request to QUEUED. The Customer

may set the STATUSlNOTIFICATION to indicate that the OASIS must notify the Customer on any change of STATUS

of transstatus (see Dynamic Notification). Prior to or commensurate with a Seller’s setting of a preconfirmed reservation

request’s STATUS to ACCEPTED (and by implication CONFIRMED), the Seller must set OFFERlPRICE equal to the

value of BIDlPRICE as established by the Customer on submission of the request.

b. The Templates (transstatus and ancstatus) shall be used by Customers and Sellers to monitor the status of their

transactions in progress. These Templates shall also be used by any Users to review the status of any transactions.

The NEGOTIATEDlPRICElFLAG data element is set when the Seller agrees to a BIDlPRICE (by setting OFFERlPRICE

equal to BIDlPRICE) that is different from the previously posted price. It will show ‘‘higher’’ when OFFERlPRICE

is higher than the posted price, and ‘‘lower’’ when the OFFERlPRICE is lower than the posted price.

c. The Templates (transsell and ancsell) shall be used by a Seller both to set a new value into STATUS and

to negotiate a price by entering a new OFFERlPRICE which is different from the BIDlPRICE entered by the Customer

in the transrequest Template (if it was not PRECONFIRMED). During these negotiations, a Reseller shall formally indicate

the approval or disapproval of a transaction and indicate which rights from prior confirmed reservations are to be

reassigned. A Primary Provider may, but is not required, to enter transaction approval or disapproval using this Template.

The valid STATUS values which may be set by a Seller are: RECEIVED, STUDY, OFFER, ACCEPTED, REFUSED, DISPLACED, ANNULLED, or RETRACTED.

d. The Customer shall use the transstatus and ancstatus Templates to view the Seller’s new offer price and/or

approval/disapproval decision.

e. After receiving notification of the transaction’s STATUS being set to ‘‘OFFER’’ by the Seller, the Templates

(transcust and anccust) shall be used by the Customer to modify the BIDlPRICE and set the STATUS to REBID.

After negotiations are complete (STATUS set to ‘‘ACCEPTED’’ by the Seller), the Customer shall formally enter the

confirmation or withdrawal of the offer to purchase services for the OFFERlPRICE shown in the transstatus Template.

The valid STATUS values which a Customer may set are: REBID, CONFIRMED, or WITHDRAWN.

f. The Seller shall use the transstatus (ancstatus) Templates to view the Customer’s new bid price and/or confirmation/

withdrawal decision, again responding through transsell or ancsell if necessary. If the Seller offers to sell a service

at an OFFERlPRICE less than that posted in the transoffering (ancoffering) Template, the transoffering (ancoffering)

Template must be updated to reflect the new OFFERlPRICE.

g. For deals consummated off the OASIS by a Seller, after the Customer has accepted the offering, the Templates

(transassign and ancassign) may be used by the Seller to notify the Primary Provider of the transfer of rights to the

Customer. Continuation records may be used to indicate the reassigning of rights for a ‘‘profile’’ of different assignments

and different capacities over different time periods.

h. The source of all user and seller contact information shall be the User registration process. Therefore, it shall

not be input as part of uploads, but shall be provided as part of all transaction downloads.

i. OASIS shall accept a seller initiated change in STATUS to ACCEPTED only when OFFERlPRICE matched

BIDlPRICE (i.e., seller must set OFFERlPRICE equal to BIDlPRICE prior to or coincident with setting STATUS to

accepted).

j. OASIS shall accept a customer initiated change in STATUS to CONFIRMED only when BIDlPRICE matches

OFFERlPRICE (i.e., customer must set BIDlPRICE equal to OFFERlPRICE prior to or coincident with setting STATUS

to confirmed).

4.2.10.2 Status Values

The possible STATUS values are:

QUEUED=initial status assigned by TSIP on receipt of ‘‘customer services purchase request’’

RECEIVED=assigned by TP to acknowledge QUEUED requests and indicate the service request is being evaluated, including

for completing the required ancillary services

STUDY=assigned by TP to indicate some level of study is required or being performed to evaluate service request

OFFER=assigned by TP to indicate that a new OFFERlPRICE is being proposed

REBID=assigned by TC to indicate that a new BIDlPRICE is being proposed

ACCEPTED=assigned by TP to indicate service request at the designated OFFERlPRICE has been approved/accepted.

If the reservation request was submitted PRECONFIRMED, OASIS shall immediately set the reservation status to CONFIRMED. Depending upon the type of ancillary services required, the Seller may or may not require all ancillary service

reservations to be completed before accepting a request.

REFUSED=assigned by TP to indicate service request has been denied, SELLERlCOMMENTS should be used to communicate reason for denial of service

CONFIRMED=assigned by TC in response to TP posting ‘‘ACCEPTED’’ status, to confirm service. Once a request has

been ‘‘CONFIRMED’’, a transmission service reservation exists

WITHDRAWN=assigned by TC at any point in request evaluation to withdraw the request from any further action

DISPLACED=assigned by TP when a ‘‘CONFIRMED’’ reservation from a TC is displaced by a longer term request and

the TC has exercised right of first refusal (i.e., refused to match terms of new request)

ANNULLED=assigned by TP when, by mutual agreement with the TC, a confirmed reservation is to be voided.

RETRACTED=assigned by TP when the TC fails to confirm or withdraw the request within the required time period

BILLING CODE 6717–01–M
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38965

BILLING CODE 6717–01–C
38966 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

4.2.10.3 Dynamic Notification

Customer’s may specify the delivery of dynamic notification messages on each change in STATUS of an ancillary

or transmission service reservation. OASIS shall support the delivery of dynamic notification messages through either

the HTTP protocol or by electronic mail. The selection of which mechanism is used and the contents of the messages

delivered to the client program or e-mail address is defined by the content of the STATUSlNOTIFICATION data

element as described in the next subsections.

Regardless of whether this dynamic notification method is used or not, it shall remain the User’s Regardless of

whether this dynamic notification method is used or not, it shall still remain the User’s responsibility to get the

desired information, possibly through the use of a periodic ‘‘integrity request’’. OASIS nodes shall not be obligated

or liable to guarantee delivery/receipt of messages via the STATUSlNOTIFICATION mechanism other than on a ‘‘best

effort’’ basis.

As an extension of the Company registration information of the host, domain and port identifiers for dynamic

notification of changes in the Customer’s purchase requests, a field should added to the Company’s registration information

that would define/identify how notification would be delivered to that Company should a transmission or ancillary

purchase request be directed to that Company as a Seller of a transmission or ancillary service. The pertinent information

would be either a full HTTP protocol URL defining the protocol, host name, port, path, resource, etc. information

or a ‘‘mailto:’’ URL with the appropriate mailbox address string. On receipt of any purchase request directed to that

Company as SELLER via either the ‘‘transrequest’’ or ‘‘ancrequest’’ templates, or on submission of any change in request

STATUS to that Company as SELLER via either the ‘‘transrequest’’ or ‘‘ancrequest’’ templates, or on submission of

any change in request STATUS to that Company as SELLER via either the ‘‘transcust’’ or ‘‘anccust’’ templates, a notification

message formatted as documented for the delivery of notification to the Customer, shall be formatted and directed

to the Seller.

4.2.10.3.1 HTTP Notification

OASIS shall deliver dynamic notification to a client system based on HTTP URL information supplied in part

by the STATUSlNOTIFICATION data element and by information supplied as part of the Customer’s Company registration

information. HTTP URL’s are formed by the concatenation of a protocol field (i.e., http:), a domain name (e.g., //

www.tsin.com), a port designation (e.g.,:80), and resource location information.

The STATUSlNOTIFICATION data element shall contain the protocol field ‘‘http:’’, which designates the notification

method/protocol to be used, followed by all resource location information required; the target domain name and port

designations shall be inserted into the notification URL based on the Customer’s Company registration information.

The resource location information may include directory information, cgi script identifiers and URL encoded query

string name/value pairs as required by the Customer’s application. OASIS performs no processing on the resource location

information other than to include it verbatim along with the protocol, domain name and port information when forming

the URL that will be used to deliver the HTTP protocol notification message.

For example, Company XYZ has established the domain name and port designations of ‘‘//oasistc.xyz.com:80’’ as

part of their registration information.

When a transmission reservation is submitted by one of the Company XYZ’s users (the Customer), and includes a

STATUSlNOTIFICATION data element with the value of ‘‘http:/cgi-bin/status? DEALlREF=8&REQUESTlREF=173’’,

OASIS shall deliver an HTTP notification message using the URL: http//oasistc.xyz.com:80/cgi-bin/status?

DEALlREF=8&REQUESTlREF=173

If the STATUSlNOTIFICATION field contained only the ‘‘http:’’ protocol designation, the notification message would

be delivered using the URL: http://oasistic.xyz.com:80

The contents of the HTTP protocol notification message delivered by OASIS shall consist of the complete URL

created by combining fields from the STATUSlNOTIFICATION data element and Company registration information

as part of an HTTP GET method request. In addition to the GET method HTTP header record, OASIS shall also

append the CSV formatted output of the transstatus template information for that particular reservation using the standard

Content-type: text/x-oasis-csv and appropriate Content-length: HTTP header records. OASIS shall use a Primary Provider

specific default value for RETURNlTZ in formulating response information.

Continuing with the previous example, the important records in the HTTP notification message that would be delivered

to Company XYZ for the transmission reservation request submitted to Primary Provider ABC and given an ASSIGNMENTlREF of 245 would be.

GET http://oasistc.xyz.com:80/cgi-bin/status?DEALlREF=8&REQUESTlREF=173 HTTP/1.0

Content-type: text/x-oasis-civ

Content-length:<byte count of remainder of message≤

REQUESTlSTATUS=200

TIMElSTAMP=<appropriate value≤

VERSION=1.2

TEMPLATE=transstatus

OUTPUTlFORMAT=DATA

PRIMARYlPROVIDERlCODE=ABC

PRIMARYlPROVIDERlDUNS=123456789

RETURNlTZ=<appropriate value for ABC≤

DATAlROWS=1

COLUMNlHEADERS=CONTINUATIONlFLAG, ASSIGNMENTlREF, . . .

N, 245, . . .

In the event an error is encountered delivering the HTTP notification message to the target URL as indicated by

a failure of the target system to respond, or return of HTTP response status of 408, 500, 503, or 504, OASIS shall

retry up to two more times, once every 5 minutes.
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38967

4.2.10.3.2 E-mail Notification

OASIS shall deliver dynamic notification to an e-mail address based on Mailto: URL information specified in the

STATUSlNOTIFICATION data element. Mailto: URL’s consist of the ‘‘mailto:’’ protocol identifier and an Internet mail

address to which the notification message should be sent. The STATUSlNOTIFICATION data element shall contain

the protocol field ‘‘mailto:’’, which designates the notification method/protocol to be used, followed by an Internet

mail address in conformance with RFC 822.OASIS shall send an e-mail message to the Internet mail address containing

the following information: ‘‘To:’’ set to the mail address from the STATUSlNOTIFICATION data element, ‘‘From:’’

set to an appropriate mail address of the OASIS node, ‘‘Subject:’’ shall be the transstatus template name followed

by the value of the ASSIGNMENTlREF data element and the current value for the STATUS data element associated

with the reservation (e.g., ‘‘subject: transstatus 245 ACCEPTED’’), and the body of the message shall contain the CSV

formatted output of the transstatus template information for that particular reservation. OASIS shall use a Primary

Provider specific default value for RETURNlTZ in formulating the transstatus response information.

4.2.11 Reference Identifiers

The TSIP shall assign a unique reference identifier, ASSIGNMENTlREF, for each Customer request to purchase

capacity or services. The value of ASSIGNMENTlREF may be used to imply the order in which the request was

received by the TSIP. This identifier will be used to track the request through various stages, and will be kept with

the service through out its life. Whenever the service is resold, a new ASSIGNMENTlREF number is assigned, but

previous ASSIGNMENTlREF numbers are also kept so that a chain of all transactions related to the service can be

maintained.

The TSIP shall assign a unique reference identifier, POSTINGlREF, to each Seller’s offerings of service for sale

or other information (messages) posted on OASIS. This identifier shall be referenced by the Seller in any/all subsequent

template submissions which would result in a modification to or deletion of that specific offering or message. Optionally,

Customers may also refer to this POSTINGlREF in their subsequent purchase requests to aid in identifying the specific

offering associated with the purchase request.

Sellers may aggregate portions of several previous transmission service reservations to create a new offering to

be posted on OASIS. When all or a portion of such offerings are sold, the Seller (original Customer) is obligated

to notify the Primary Provider of the sale/assignment by inserting appropriate reassignment information on OASIS (via

the transsell or transassign templates) or by some other approved method. This reassignment information consists of

the ASSIGNMENTlREF value assigned to the original reservation(s) and the time interval and capacity amount(s) being

reassigned to the new reservation. These values are retained in the REASSIGNEDlREF, REASSIGNEDlSTARTlTIME,

REASSIGNEDlSTOPlTIME, and REASSIGNEDlCAPACITY data elements.

Sellers may identify their service offerings received from customers through the Seller supplied value specified

for the SALElREF data element.

Customers may track their purchase requests through the Customer supplied values specified for the DEALlREF

and REQUESTlREF data elements. Customers may also use POSTINGlREF and SALElREF in their purchase requests

to refer back to posted offerings.

4.2.12 Linking of Ancillary Services to Transmission Services

The requirements related to ancillary services are shown in transoffering (and updated using transupdate) using

the ANClSVClREQ data element containing the following permitted values:

SC:x; RV:x; RF:x; EI:x; SP:x; SU:x;

where SC, RV, RF, EI, SP and SU are the ancillary services 1 through 6 describe din the Proforma Tariff,

• SC—Scheduling, system Control and dispatch

• RV—Reactive supply and Voltage control

• RF—Regulation and Frequency response

• EI—Energy Imbalance

• SP—SPinning reserve

• SU—SUpplemental reserve

and where x={M,R,O,U} means one of the following:

• Mandatory, which implies that the Primary Provider must provide the ancillary service

• Required, which implies that the ancillary service is required, but not necessarily from the Primary Provider

• Optional, which implies that the ancillary service is not necessarily required, but could be provided

• Unknown, which implies that the requirements for the ancillary service are not known at this time

Ancillary services may be requested by a User from the Provider at the same time as transmission services are

requested via the transrequest template, by entering the special codes into ANClSVClLINK to represent the Proformad

ancillary services 1 through 6 (or more) as follows:

SC:(AA); RV:(AA); RF:(AA[:xxx[:yyy[:nnn]]]); EI:(AA[:xxx[:yyy[:nnn]]]);

SP:(AA[:xxx[:yyy[:nnn]]]); SU:(AA[:xxx[:yyy[:nnn]]]);

{Registered}:(AA[:xxx[:yyy[:nnn]]])

where AA is the appropriate PRIMARYlPROVIDERlCODE, SELLERlCODE, or CUSTOMERlCODE, and represents

the company providing the ancillary services. ‘‘AA’’ may be unspecified for ‘‘xxx’’ type identical to ‘‘FT’’, in which

case the ‘‘:’’ character must be present and precede the‘‘FT’’ type.

If multiple ‘‘AA’’ terms are necessary, then each ‘‘AA’’ grouping will be enclosed within parenthesis, with the

overall group subordinate to the ANClSVClTYPE specified within parenthesis.

and where xxx represents either:

l‘‘FT’’ to indicate that the Customer will determine ancillary services at a future time, or
38968 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

l‘‘SP’’ to indicate that the Customer will self-provide the ancillary services, or

l‘‘RQ’’ to indicate that the Customer is asking the OASIS to initiate the process for making an ancillary services

reservation with the indicated Provider or Seller on behalf of the Customer. The Customer must then continue the

reservation process with the Provider or Seller. If the transmission services request is for preconfirmed service, then

the ancillary services shall be preconfirmed, or

l‘‘AR’’ to indicate an assignment reference number sequence follows.

The terms ‘‘yyy’’ and ‘‘nnn’’ are subordinate to the xxx type of ‘‘AR’’.yyy represents the capacity of the reserved

ancillary services. Square brackets are used to indicated optional elements and are not used in the actual linkage

itself. Specifically, the :yyy is applicable to only the ‘‘AR’’ term and the :nnn may optionally be left off if the capacity

of ancillary services is the same as for the transmission services, and optionally multiple ancillary reservations may

be indicated by additional (xxx[:yyy[:nnn]]) enclosed within parenthesis. If no capacity amount is indicated, the required

capacity is assumed to come from the ancillary reservations in the order indicated in the codes, on an ‘‘as-needed’’

basis.

Examples:

Example 1:

Assume ancillary services SC and RV are mandatory from the TP, whose code is ‘‘TPEL’’, and ancillary services

RF, EI, SP and SU are required, but will be defined at a future time.

‘‘SC: (TPEL:RQ); RV:(TPEL:RQ); RF:(:FT); EI:(:FT); SP:(:FT); SU:(:FT)’’

Example 2:

Assume ancillary services SC and RV are mandatory from the TP, whose code is ‘‘TPEL’’, and RF, EI, SP and

SU are self-supplied. The customer code is ‘‘CPSE’’

‘‘SC:(TPEL:RQ); RV:(TPEL:RQ); RF:(CPSE:SP); EI:(CPSE:SP); SP:(CPSE:SP); SU:(CPSE:SP)’’

Example 3:

Assume ancillary services SC and RV are mandatory from the TP, whose code is ‘‘TPEL’’, and ancillary services

RF, EI, SP and SU were purchased via a prior OASIS reservation from seller ‘‘SANC’’ whose reservation number was

‘‘39843’’. There is sufficient capacity within the Ancillary reservation to handle this Transmission reservation.

‘‘SC:(TPEL:RQ); RV:(TPEL:RQ); RF:(SANC:AR:39843); EI:(SANC:AR:AR:39843) SP:(SANC:AR:39843); SU:(SANC:AR:39843)’’

Example 4:

Assume ancillary services SC and RV are mandatory from the TP, whose code is ‘‘TPEL’’, and ancillary services

RF, EI, SP and SU were purchased via prior OASIS reservations from sellers ‘‘SANC’’ and ‘‘TANC’’, whose reservation

numbers were ‘‘8763’’ and ‘‘9824’’ respectively. There is not sufficient capacity within the Ancillary reservation from

seller ‘‘SANC’’ to handle this Transmission reservation. In this case the OASIS reservation number 8763 will be depleted

for the time frame specified within the transmission reservation and the remaining required amount will come from

reservation number ‘‘9824’’.

‘‘SC:(TPEL:RQ); RV:(TPEL:RQ); RF:((SANC:AR:8763)(TANC:AR:9824)); EI:((SANC:AR:8763)(TANC:AR:9824));

SP:((SANC:AR:8763)(TANC:AR:9824)); SU:((SANC:AR:8763)(TANC:AR:9824))’’

Example 5:

Assume a transmission reservation in the amount of 100 mw/hour for a period of one day is made. Ancillary

services SC and RV are mandatory from the TP, whose code is ‘‘TPEL’’, and ancillary services RF, EI, SP and SU

were purchased via prior OASIS reservations from sellers ‘‘SANC’’ and ‘‘TANC’’, whose reservation numbers were ‘‘8763’’

and ‘‘9824’’ respectively. There is sufficient capacity within the Ancillary reservation from seller ‘‘SANC’’ to handle

this Transmission reservation, however the purchaser wishes to use only ‘‘40 mw’s’’ from this seller. In this case

the OASIS reservation number 8763 will be deplete in the amount of ‘‘40 mw’s’’ for the time frame specified within

the transmission reservation and the remaining required amount will come from reservation number ‘‘9824’’.

‘‘SC:(TPEL:RQ); RV:(TPEL:RQ); RF:((SANC:AR:8763:40)(TANC:AR:9824)); EI:((SANC:AR:8763:40)(TANC:AR:9824));

SP:((SANC:AR:8763:40)(TANC:AR:9824)); SU:((SANC:AR:8763:40)(TANC:AR:9824))’’

4.3 Template Descriptions

The following OASIS Templates define the Data Elements in fixed number and sequence which must be provided

for all data transfers to and from the OASIS nodes. The definitions of the data elements are listed in the Data Element

Dictionary in Appendix A.

TSIPs must provide a more detailed supplemental definition of the list of Sellers, Paths, Point of Receipt (POR),

Point of Delivery (POD), Capacity Types, Ancillary Service Types and Templates online, clarifying how the terms are

being used (see LIST Template). If POR and POD are not used, then Path Name must include directionality.

Many of the Templates represent query-response interactions between the User and the OASIS Node. These interactions

are indicated by the ‘‘Query’’ and ‘‘Response’’ section respectively of each Template. Some, as noted in their descriptions,

are Input information, sent from the User to the OASIS Node. The Response is generally a mirror of the Input, although

in some Templates, the TSIP must add some information.

4.3.1 Template Summary

The following table provides a summary of the process areas, and Templates to be used by Users to query information

that will be downloaded or to upload information to the Primary Providers. These processes define the functions that

must be supported by an OASIS Node.
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38969

Process Area Process Name Template(s)

4.3.2 Query/Response of Posted Services Being Offered ..... Query/Response Transmission Capacity Offerings .................. transoffering

Query/Response Ancillary Service Offerings ........................... ancoffering

4.3.3 Query/Response of Services Information ...................... Query/Response Transmission Services. transserv

Query/Response Ancillary Services ......................................... ancserv

4.3.4 Query/Response of Schedules and Curtailments ......... Query/Response Transmission Schedules ............................... schedule

Query/Response Curtailments .................................................. curtail

4.3.5 Query/Response of Lists of Information ........................ Query/Response List of Sellers, Paths, PORs, PODs, Capacity Types, Ancillary Service Types, Templates.list

4.3.6 Query/Response of Audit Log ....................................... Query/Response Audit Log ....................................................... auditlog

4.3.7 Purchase Transmission Services .................................. Request Purchase of Transmission Services (Input) ............... transrequest

Query/Response Status of Transmission Service Request ..... transstatus

Seller Approves Purchase (Input) ............................................. transsell

Customer Confirm/Withdraw Purchase of Transmission Service (Input).transcust

Alternate POD/POR .................................................................. transalt

Seller Reassign Rights (Input) .................................................. transassign

4.3.8 Seller Posting of Transmission Service ......................... Seller Post Transmission Service for Sale (Input) ................... transpost

Seller Modify (Remove) Transmission Service for Sale (Input) transupdate

4.3.9 Purchase of Ancillary Service ........................................ Request Purchase of Ancillary Service (Input) ......................... ancrequest

Query/Response Status of Ancillary Service Request ............. ancstatus

Seller Approves Purchase of Ancillary Service (Input) ............ ancsell

Customer Accept/Withdraw Purchase of Ancillary Service

(Input).

anccust

4.3.10 Seller Post Ancillary Service ....................................... Seller Post Ancillary Service (Input) ......................................... ancpost

Seller Modify (Remove) Ancillary Service for Sale (Input) ....... ancupdate

4.3.11 Informal Messages ...................................................... Post Want Ads (Input) .............................................................. messagepost

Query/Response Want Ads ...................................................... message

Delete Want Ad (Input) ............................................................. messagedelete

Discretion .................................................................................. discretion

Standards of Conduct ............................................................... stdconduct

4.3.2 Query/Response of Posted Services Being Offered

The following Templates define the information to be posted on services offered for sale. All discounts for service

negotiated by a Customer and Primary Provider (as Seller) at a price less than the currently posted offering price

shall be posted on OASIS in such a manner as to be viewed using these Templates. All secondary market and/or

third-party posting and Primary Provider offerings for like services shall also be viewed using these templates.

The Query must start with the standard header Query Variable Data Elements, listed in Section 4.2.6.2, and may

include any valid combination of the remaining Query Variable, shown below in the Templates. STARTlTIME and

STOPlTIME is the requested time interval for the Response to show all offerings which intersect that interval (see

Section 4.2.6.6.). TIMElOFlLASTlUPDATE can be used to specify all services updated since a specific point in

time.

Query variable listed with an asterix (*) can have at least 4 multiple instances defined by the user in making

the query.

In the Response, OFFERlSTARTlTIME and OFFERlSTOPlTIME indicate the ‘‘request time window’’ within which

a customer must request a service in order to get the post OFFERlPRICE. STARTlTIME and STOPlTIME indicate

the time frame that the service is being offered for.

The SERVICElDESCRIPTION data element shall define any attributes and/or special terms and conditions applicable

to the offering that are not listed under the standard SERVICElDESCRIPTION associated with the product definition

supplied in the transserv or ancsery templates.

SERVICElDESCRIPTION shall be null if there are no unique attributes or terms associated with the offering.

4.3.2.1 Transmission Capacity Offerings Available for Purchase (transoffering)

Transmission Services Offerings Available for Purchase (transoffering) is used to offer transmission services that

are posted for sale by the Primary Provider or Resellers. At a minimum this Template must be used to post TTC

and each increment and type of service required by applicable regulations and the Primary Provider’s tariffs.

This Templates must include, for each posted path, the Primary Provider’s TTC, firm ATC and non-firm ATC,

as required by FERC orders 888 and 889 (plus revisions) and/or if provided in the Primary Provider’s tariff. Additional

transmission services may be offered with the same Template.

The POSTINGlREF is set by the TSIP when an offering is posted and can be used in transrequests to refer to

a particular offering.

A User may query information about services available from all sellers for the time frame specified by the SERVICElINCREMENT data element, namely, hourly, daily, weekly, monthly, or yearly.

Template: transoffering

1. Query

PATHlNAME*

SELLERlCODE*

SELLERlDUNS*
38970 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

POINTlOFlRECEIPT*

POINTlOFlDELIVERY*

SERVICElINCREMENT*

TSlCLASS*

TSlTYPE*

TSlPERIOD*

STARTlTIME (of transmission services)

STOPlTIME (of transmission services)

POSTINGlREF

TIMElOFlLASTlUPDATE

2. Response

The response is one or more records showing the requested service information. Note that the Customer will receive

as a series of records spanning all the SELLERlCODEs, PATHlNAMEs, PORs, PODs, Tslxxx, and the STARTlTIME/

STOPlTIME specified in the query. The SALElREF is a value provided by the SELLER to identify the transmission

service product being sold. The ANClSVClREQ indicates all ancillary services required for the specified transmission

services. All Templates elements are defined in the Data Element Dictionary.

TIMElOFlLASTlUPDATE

SELLERlCODE

SELLERlDUNS

PATHlNAME

POINTlOFlRECEIPT

POINTlOFlDELIVERY

INTERFACElTYPE

OFFERlSTARTlTIME

OFFERlSTOPlTIME

STARTlTIME

STOPlTIME

CAPACITY

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlWINDOW

TSlSUBCLASS

ANClSVClREQ

SALElREF

POSTING REF

CEILING PRICE

OFFERlPRICE

PRICElUNITS

SERVICElDESCRITION (if null, then look at transserv)

NERClCURTAILMENTlPRIORITY

OTHERlCURTAIMENTlPRIORITY

SELLERlNAME

SELLERlPHONE

SELLERlFAX

SELLERlEMAIL

SELLERlCOMMENTS

4.3.2.2 Ancillary Services Available for Purchase (ancoffering)

Ancillary Services Available for Purchase (ancoffering) is used to provide information regarding the ancillary services

that are available for sale by all sellers (both Primary Provider and Third Party Sellers.)

Template: ancoffering

1. Query

SELLERlCODE*

SELLERlDUNS*

CONTROLlAREA*

SERVICElINCREMENT*

ANClSERVICElTYPE*

STARTlTIME

STOPlTIME

POSTINGlREF

TIMElOFlLASTlUPDATE

2. Response

TIMElOFlLASTlUPDATE
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38971

SELLERlCODE

SELLERlDUNS

CONTROLlAREA

OFFERlSTARTlTIME

OFFERlSTOPlTIME

STARTlTIME

STOPlTIME

CAPACITY

SERVICElINCREMENT

ANCILLARYlSERVICElTYPE

SALElREF

POSTINGlREF

CEILINGlPRICE

OFFERlPRICE

PRICElUNITS

SERVICElDESCRIPTION (if blank, then look at ancserv)

SELLERlNAME

SELLERlPHONE

SELLERlFAX

SELLERlEMAIL

SELLERlCOMMENTS

4.3.3. Query/Response of Services Information

4.3.3.1 Transmission Services (transserv)

Transmission Services (transserv) is used to provide additional information regarding the transmission services SERVICElINCREMENT, TSlCLASS, TSlTYPE, TSlPERIOD, TSlSUBCLASS, TSlWINDOW,

NERClCURTAIMENTlPRIORITY, and OTHERlCURTAIMENTlPRIORITY that are available for sale for a Provider

in the Templates in Section 4.3.2. This Template is used to summarize Provider tariff information for the convenience

of the User. The Provider also sets PRICElUNITS with this Template.

Template: transserv

1. Query

TIMElOFlLASTlUPDATE

2. Response

TIMElOFlLASTlUPDATE

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlWINDOW

TSlSUBCLASS

CEILINGlPRICE

PRICElUNITS

SERVICElDESCRIPTION

NERClCURTAILMENTlPRIORITY

OTHERlCURTIMENTlPRIORITY

TARIFFlREFERENCE

4.3.3.2 Ancillary Services (ancserv)

Ancillary Services (ancserv) is used to provide additional information regarding the ancillary services that are available

for sale by a Provider in the Templates in Section 4.3.2. This Template is used to summarize Provider tariff information

for the convenience of the User. The Provider also sets PRICElUNITS with this Template.

Template: ancserv

1. Query

TIMElOFlLASTlUPDATE

2. Response

TIMElOFlLASTlUPDATE

SERVICElINCREMENT

ANClSERVICElTYPE

CEILINGlPRICE

PRICElUNITS

SERVICElDESCRIPTION

TARIFFlREFERENCE
38972 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

4.3.4 Query/Response of Schedules and Curtailments

4.3.4.1 Hourly Schedule (schedule)

Hourly Schedule (schedule) is used to show what a Provider’s scheduled transmission capacity usage actually was

for specific Paths. All the information provided is derived from that in the transmission reservation (see Template

transstatus), except CAPACITYlSCHEDULED, which is the amount of the reservation which was scheduled. Posting

of the schedules is organized around the transmission reservations, not the energy schedules. This may require the

Primary Provider to map schedules back to the reservation. These records would have to be created for all reservations/

schedules done off the OASIS during the operations scheduling period.

Template: schedule

1. Query

PATHlNAME*

SELLERlCODE*

SELLERlDUNS*

CUSTOMERlCODE*

CUSTOMERlDUNS*

POINTlOFlRECEIPT*

POINTlOFlDELIVERY*

SERVICElINCREMENT*

TSlCLASS*

TSlTYPE*

TSlPERIOD*

STARTlTIME

STOPlTIME

TIMElOFlLASTlUPDATE

ASSIGNMENTlREF

2. Response

TIMElOFlLASTlUPDATE

SELLERlCODE

SELLERlDUNS

PATHlNAME

POINTlOFlRECEIPT

POINTlOFlDELIVERY

CUSTOMERlCODE

CUSTOMERlDUNS

AFFILIATElFLAG

STARTlTIME (start time of schedule)

STOPlTIME (stop time of schedule)

CAPACITY (reserved)

CAPACITYlSCHEDULED (total of energy scheduled for this customer for this reservation for this hour)

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlWINDOW

TSlSUBCLASS

NERClCURTAILMENTlPRIORITY

OTHERlCURTAILMENTlPRIORITY

ASSIGNMENTlREF (Last rights holder)

4.3.4.2 Curtailment/Interruption (curtail)

Curtailment/Interruption (curtail) provides additional information about the actual curtailment of transmission reservations that have been scheduled for energy exchange. All fields are derived from the reservation except the CAPACITYlCURTAILED, CURTAILMENTlREASON and CURTAILMENTlOPTIONS. These fields provide information on the

reasons for the curtailment procedures to be followed and options for the Customer, if any, to relieve the curtailment.

Template: curtail

1. Query

PATHlNAME*

SELLERlCODE*

SELLERlDUNS*

CUSTOMERlCODE*

CUSTOMERlDUNS*

POINTlOFlRECEIPT*

POINTlOFlDELIVERY*
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38973

SERVICElINCREMENT*

TSlCLASS*

TSlTYPE*

TSlPERIOD*

STARTlTIME

STOPlTIME

TIMElOFlLASTlUPDATE

ASSIGNMENTlREF

2. Response

TIMElOFlLASTlUPDATE

SELLERlCODE

SELLERlDUNS

PATHlNAME

POINTlOFlRECEIPT

POINTlOFlDELIVERY

CUSTOMERlCODE

CUSTOMERlDUNS

AFFILIATElFLAG

STARTlTIME (Start time of curtailment)

STOPlTIME (Stop time of curtailment)

CAPACITY (Capacity reserved)

CAPACITYlSCHEDULED

CAPACITYlCURTAILED

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlWINDOW

TSlSUBCLASS

NERClCURTAILMENTlPRIORITY

OTHERlCURTAILMENTlPRIORITY

CURTAILMENTlREASON

CURTAILMENTlPROCEDURES

CURTAILMENTlOPTIONS

ASSIGNMENTlREF

4.3.5 Query/Response of Lists of Information

4.3.5.1 List (list)

List (list) is used to provide lists of valid names. The minimum set of lists is LIST, SELLERlCODEs, PATHs,

PORs, PODs, SERVICElINCREMENTs, TSlCLASSes, TSlTYPEs, TSlPERIODS, NERClCURTAILMENTlPRIORITY,

OTHERlCURTAILMENTlPRIORITY, ANCILLARYlSERVICElTYPEs, CATEGORYs, and TEMPLATEs. These names may

be used to query information, post or request services.

Template: list

1. Query

LISTlNAME

TIMElOFlLASTlUPDATE

2. Response

TIMElOFlLASTlUPDATE

LISTlNAME

LISTlITEM

LISTlITEMlDESCRIPTION

4.3.6 Query/Response to Obtain the Audit log

4.3.6.1 Audit Log Information (auditlog)

Audit Log Information (auditlog) is used to provide a means of accessing the required audit information. The TSIP

will maintain two types of logs:

a. Log of changes posted TS Information, such as CAPACITY. This log will record as a minimum the time of

the change, the Template name, the name of the Template data element changed and the old and new values of

the Template data element.

b. A complete record of all transaction events, such as those contained in the Templates 4.3.8, 4.3.9 and 4.3.10.

For transaction event logs, the response will include: TIMElSTAMP, TEMPLATE, ELEMENTlNAME, AND NEWlDATA.

In this case the value of OLDlDATA is not applicable.

Template: auditlog

1. Query

STARTlTIME (search against audit log)
38974 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

STOPlTIME (search against audit log)

2. Response

ASSIGNMENTlREF OR POSTINGlREF

TIMElSTAMP

TEMPLATE

ELEMENTlNAME (for data elements whose values have changed)

OLDlDATA

4.3.7 Purchase Transmission Service

The following Templates shall be used by Customers and Sellers to transact purchases of services.

4.3.7.1 Customer Capacity Purchase Request (transrequest)

The Customer Capacity Purchase Request (Input) (transrequest) is used by the Customer to request the purchase

of transmission services. The resp[onse simply acknowledges that the Customer’s request was received by the OASIS

Node. It does not imply that the Seller has received the request. Input ting values into the reference Data Elements

is optional.

CUSTOMERlCODE and CUSTOMERlDUNS shall be determined from the registered connection used to input the

request.

Supporting ‘‘profiles’’ of services, which request different capacities for different time periods within a single request,

is at the discretion of the Primary Provider. Continuation records may be used to indicate requests for these service

profiles. Only the following fields may be redefined in a continuation record for the transrequest Template: CAPACITY,

BIDlPRICE, STARTlTIME, AND STOPlTIME.

For requesting transmission services which include multiple paths, only the following fields may be redefined in

a continuation record for the transrequest Template. PATHlNAME. Supporting multiple paths is at the discretion of

the Provider.

The STARTlTIME and STOPlTIME indicate the requested period of service.

When the request is received at the OASIS Node, the TSIP assigns a unique ASSIGNMENTlREF value and queues

the request with a time stamp. The STATUS for the request is QUEUED.

Specification of a value YES in the PRECONFIRMED field authorizes the TSIP to automatically change the STATUS

field in the transstatus Template to CONFIRMED when that request is ACCEPTED by the Seller.

Template: transrequest

1. Input

CONTINUATIONlFLAG

SELLERlCODE (Primary or Reseller)

SELLERlDUNS

PATHlNAME

POINTlOFlRECEIPT

POINTlOFlDELIVERY

SOURCE

SINK

CAPACITY

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlSUBCLASS

STATUSlNOTIFICATION

STARTlTIME

STOPlTIME

BIDlPRICE

PRECONFIRMED

ANClSVClLINK

POSTINGlREF (Optionally set by Customer)

SALElREF (Optionally set by Customer)

REQUESTlREF (Optionally set by Customer)

DEALlREF (Optionally set by Customer)

CUSTOMERlCOMMENTS

2. Response (acknowledgment)

RECORDlSTATUS

CONTINUATIONlFLAG

ASSIGNMENTlREF (assigned by TSIP)

SELLERlCODE

SELLERlDUNS

PATHlNAME

POINTlOFlRECEIPT
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38975

POINTlOFlDELIVERY

SOURCE

SINK

CAPACITY

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlSUBCLASS

STATUSlNOTIFICATION

STARTlTIME

STOPlTIME

BIDlPRICE

PRECONFIRMED

ANClSVClLINK

POSTINGlREF

SALElREF

REQUESTlREF

DEALlREF

CUSTOMERlCOMMENTS

ERRORlMESSAGE

4.3.7.2 Status of Customer Purchase Request (transstatus)

The Status of Customer Purchase Request (transstatus) is provided upon the request of any Customer or Provider

to indicate the current status of one or more reservation records. Users may also view any transaction’s status. Transmission

Providers shall make source and sink information available at the time the request status posting is updated to show

that a transmission request is confirmed.

Only the following fields may be redefined in a continuation record for the transstatus response Template:

PATHlNAME, CAPACITY, STARTlTIME, STOPlTIME, REASSIGNEDlREF, REASSIGNEDlCAPACITY, REASSIGNEDlSTARTlTIME, and REASSIGNEDlSTOPlTIME.

The AFFILIATElFLAG will be set by the TSIP to indicate whether or not the Customer is an affiliate of the

Primary Provider. The NEGOTIATEDlPRICElFLAG will be set by the TSIP to indicate whether the OFFERlPRICE

is higher, lower, or the same as the BIDlPRICE.

Template: transstatus

1. Query

SELLERlCODE*

SELLERlDUNS*

CUSTOMERlCODE*

CUSTOMERlDUNS*

PATHlNAME*

POINTlOFlRECEIPT*

POINTlOFlDELIVERY*

SERVICElINCREMENT*

TSlCLASS*

TSlTYPE*

TSlPERIOD*

STATUS*

STARTlTIME (Beginning time of service)

STOPlTIME

STARTlTIMElQUEUED (Beginning time queue)

STOPlTIMElQUEUED

NEGOTIATEDlPRICElFLAG

ASSIGNMENTlREF

REASSIGNEDlREF

SALElREF

REQUESTlREF

DEALlREF

TIMElOFlLASTlUPDATE

2. Response

CONTINUATIONlFLAG

ASSIGNMENTlREF

SELLERlCODE

SELLERlDUNS

CUSTOMERlCODE

CUSTOMERlDUNS

AFFILIATElFLAG (Set by TSIP)
38976 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

PATHlNAME

POINTlOFlRECEIPT

POINTlOFlDELIVERY

SOURCE

SINK

CAPACITY (total reservation)

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlWINDOW

TSlSUBCLASS

NERClCURTAILMENTlPRIORITY

OTHERlCURTAILMENTlPRIORITY

STARTlTIME

STOPlTIME

CEILINGlPRICE

OFFERlPRICE

BIDlPRICE

PRECONFIRMED

ANClSVClLINK

ANClSVClREQ

ALTERNATElSERVICElFLAG

POSTINGlREF

SALElREF

REQUESTlREF

DEALlREF

NEGOTIATEDlPRICElFLAG (‘‘L’’ if Seller accepted Price is lower than OFFERlPRICE in transoffering Template; ‘‘H’’

if higher; otherwise blank)

STATUS=RECEIVED, QUEUED, STUDY, REBID, OFFER, ACCEPTED, REFUSED, CONFIRMED, WITHDRAWN, DISPLACED,

ANNULLED, RETRACTED

STATUSlNOTIFICATION

STATUSlCOMMENTS

TIMElQUEUED

RESPONSElTIMElLIMIT

TIMElOFlLASTlUPDATE

PRIMARYlPROVIDERlCOMMENTS

SELLERlCOMMENTS

CUSTOMERlCOMMENTS

SELLERlNAME

SELLERlPHONE

SELLERlFAX

SELLERlEMAIL

CUSTOMERlNAME

CUSTOMERlPHONE

CUSTOMERlFAX

CUSTOMERlEMAIL

REASSIGNEDlREF

REASSIGNEDlCAPACITY (Capacity from each previous transaction)

REASSIGNEDlSTARTlTIME

REASSIGNEDlSTOPlTIME

4.3.7.3 Seller Approval of Purchase (transsell)

Seller Approval of Purchase (Input) (transsell) is input by a Seller to modify the status and queue of a request

by a Customer.

If preconfirmed then Seller can only change values of data elements, STATUS, STATUSlCOMMENTS, SELLERlCOMMENTS, REASSIGNEDlREF, NEGOTIATEDlPRICElFLAG, ANClSRVlREQ, REASSIGNEDlSTARTlTIME,

REASSIGNEDlSTOPlTIME, and REASSIGNEDlCAPACITY. If not preconfirmed, then the Seller can also change

OFFERlPRICE.

Only the following fields may be redefined in a continuation record for the transsell Template: REASSIGNEDlCAPACITY, OFFERlPRICE, REASSIGNEDlREF, REASSIGNEDlSTARTlTIME, and REASSIGNEDlSTOPlTIME.

SELLERlCODE and SELLERlDUNS shall be determined from the registered connection used to input the request.

The Seller may accept a reservation only when the BIDlPRICE and the OFFERlPRICE are the same.

Template: transsell

1. Input

CONTINUATIONlFLAG
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38977

ASSIGNMENTlREF (Required)

OFFERlPRICE

STATUS=RECEIVED, STUDY, OFFER, ACCEPTED, REFUSED, ANNULLED, RETRACTED, DISPLACED

STATUSlCOMMENTS

OTHERlCURTAILMENTlPROPERTY (optional)

ANClSVClREQ

NEGOTIATEDlPRICElFLAG

SELLERlCOMMENTS

RESPONSElTIMElLIMIT

REASSIGNEDlREF

REASSIGNEDlCAPACITY (Previous capacity to be reassigned)

REASSIGNEDlSTARTlTIME

REASSIGNEDlSTOPlTIME

2. Response

RECORDlSTATUS

CONTINUATIONlFLAG

ASSIGNMENTlREF

OFFERlPRICE

STATUS=RECEIVED, STUDY, OFFER, ACCEPTED, REFUSED, ANNULLED, RETRACTED, DISPLACED

STATUSlCOMMENTS

OTHERlCURTAILMENTlPRIORITY

ANClSVClREQ

NEGOTIATEDlPRICElFLAG

SELLERlCOMMENTS

RESPONSElTIMElLIMIT

REASSIGNEDlREF

REASSIGNEDlCAPACITY (Previous capacity to be reassigned)

REASSIGNEDlSTARTlTIME

REASSIGNEDlSTOPlTIME

ERRORlMESSAGE

4.3.7.4 Customer Confirmation of Purchase (Input) (Transcust)

Customer Confirmation of Purchase (Input) (transcust) is input by the Customer to state his agreement or withdrawal

of a purchase after the Seller has indicated that the purchase request is approved. Only the BIDlPRICE, STATUS,

STATUSlCOMMENTS, ANClSVClLINK, and CUSTOMERlCOMMENTS data elements can be modified in this Template.

CUSTOMERlCODE and CUSTOMERlDUNS shall be determined from the registered connection used to input the

request.

The Customer must change the BIDlPRICE to be equal to the OFFERlPRICE for each record before the STATUS

can be set to CONFIRMED.

Template: transcust

1. Input

CONTINUATIONl

ASSIGNMENTlREF (Required)

REQUESTlREF

DEALlREF

BIDlPRICE

STATUS=REBID, CONFIRMED, WITHDRAWN

STATUSlCOMMENTS

ANClSVClLINK

STATUSlNOTIFICATION If left blank, then original URL from the transrequest will be used

CUSTOMERlCOMMENTS

2. Response

RECORDlSTATUS

CONTINUATIONlFLAG

ASSIGNMENTlREF

REQUESTlREF

DEALlREF

BIDlPRICE

STATUS=REBID, CONFIRMED, WITHDRAWN

STATUSlCOMMENTS

ANClSVClLINK

STATUSlNOTIFICATION

CUSTOMERlCOMMENTS

ERRORlMESSAGE
38978 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

4.3.7.5 Alternate Point of Receipt/Delivery (transalt)

Alternate Point of Delivery (transalt). The Customer may submit a request to use alternate points of receipt/delivery

for an existing confirmed reservation, if allowed by applicable tariffs and service agreements. The assignment reference

value associated with the prior confirmed reservation must be provided in the REASSIGNEDlREF data element along

with the alternate points of receipt/delivery. The request may be submitted as PRECONFIRMED. Requests submitted

by the transalt template shall be handled by OASIS identically to reservations submitted using the transrequest template.

CUSTOMERlCODE and CUSTOMERlDUNS shall be determined from the registered connection used to input the

request.

REASSIGNEDlREF contains the ASSIGNMENTlREF of the original, confirmed reservation that is being designated

to the alternate points of delivery/receipt. The Template allows for only one REASSIGNEDlREF field. Therefore, if

multiple, original reservations are being designated, a separate transalt Template must be submitted associated with

each original reservation. There is no restriction that multiple submissions of the transalt Template may all refer back

to the same, original reservation (i.e., may have the same REASSIGNEDlREF).

Demand profiles associated with the designation of alternate POD/POR may be submitted by additional records

designating ‘‘Y’’ for CONTINUATIONlFLAG, and specifying the CAPACITY, STARTlTIME, and STOPlTIME data

elements corresponding to the MW demand being requested over each time interval associated with the reservation.

The CAPACITY, STARTlTIME, and STOPlTIME data elements must fall within the amounts and time intervals associated with the original reservation.

The following data elements in transstatus and the appropriate ones in transcust shall take on the following implied

values:

SELLERlCODE (value from SELLERlCODE in reservation designated by REASSIGNEDlREF)

SELLERlDUNS (value from SELLERlDUNS in reservation designated by REASSIGNEDlREF)

ALTERNATElSERVICElFLAG=YES

OFFERlPRICE=$0

BIDlPRICE=$0

CEILINGlPRICE=$0

TSlCLASS=Non-Firm (or whatever the Provider designates)

REASSIGNEDlCAPACITY=MW capacity submitted in CAPACITY field of Template

REASSIGNEDlSTARTlTIME=time submitted in STARTlTIME field of Template

REASSIGNEDlSTOPlTIME=time submitted in STOPlTIME field of Template

Template: transalt

1. Input

CONTINUATIONlFLAG

PATHlNAME

POINTlOFlDELIVERY

SOURCE

SINK

PRECONFIRMED

CAPACITY (Must be less than or equal to original capacity reservation)

STATUSlNOTIFICATION

STARTlTIME (Valid only to hour and within the time of original reservation)

STOPlTIME (Valid only to hour and within the time of original reservation)

CUSTOMERlCOMMENTS

2. Response (acknowledgment)

RECORDlSTATUS

CONTINUATIONlFLAG

ASSIGNMENTlREF (assigned by the TSIP)

SELLERlCODE (Primary)

SELLERlDUNS

PATHlNAME

POINTlOFlRECEIPT

POINTlOFlDELIVERY

SOURCE

SINK

PRECONFIRMED

ALTERNATElSERVICElFLAG (Defaulted to YES)

CAPACITY (Capacity requested)

STATUSlNOTIFICATION

STARTlTIME

STOPlTIME

REQUESTlREF

DEALlREF

REASSIGNEDlREF (Assignment Reference for the Firm reservation being used for request)

4.3.7.6 Seller to Reassign Service Rights to Another Customer (transassign)

Seller to Reassign Service Rights to Another Customer (Input) (transassign) is used by the seller to ask the Transmission

Services Information Provider to reassign some or all of the seller’s rights to Services to another Customer, for seller
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38979

confirmed transactions that have occurred off the OASIS. The TSIP shall assign a unique ASSIGNMENTlREF in the

response (acknowledgment) and enter the status CONFIRMED as viewed in the transstatus Template.

SELLERlCODE and SELLERlDUNS shall be determined from the registered connection used to input the request.

Only the following fields may be redefined in a continuation record for the transassign input Template: CAPACITY,

STARTlTIME, STOPlTIME, REASSIGNEDlREF, REASSIGNEDlCAPACITY, REASSIGNEDlSTARTlTIME, and REASSIGNEDlSTOPlTIME.

SELLERlCODE and SELLERlDUNS shall be determined form the registered connection used to input the request.

Template: transassign

1. Input

CONTINUATIONlFLAG

CUSTOMERlCODE

CUSTOMERlDUNS

PATHlNAME

POINTlOFlRECEIPT

POINTlOFlDELIVERY

SOURCE

SINK

CAPACITY

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlSUBCLASS

STARTlTIME

STOPlTIME

OFFERlPRICE

ANClSVCXlLINK (optional: filled in if assignment is different than original transmission reservation)

POSTINGlNAME

REASSIGNEDlREF

REASSIGNEDlCAPACITY (Capacity being sold from each previous assignment)

REASSIGNEDlSTARTlTIME

REASSIGNEDlSTOPlTIME

SELLERlCOMMENTS

2. Response (acknowledgment)

RECORDlSTATUS

CONTINUATIONlFLAG

ASSIGNMENTlREF (assigned by TSIP)

CUSTOMERlCODE

CUSTOMERlDUNS

PATHlNAME

POINTlOFlRECEIPT

POINTlOFlDELIVERY

SOURCE

SINK

CAPACITY (Total capacity being reassigned)

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlSUBCLASS

STARTlTIME

STOPlTIME

OFFERlPRICE

ANClSVClLINK

POSTINGlNAME

REASSIGNEDlREF

REASSIGNEDlCAPACITY (Capacity being sold from each previous assignment)

REASSIGNEDlSTARTlTIME

REASSIGNEDlSTOPlTIME

SELLERlCOMMENTS

ERRORlMESSAGE

4.3.8 Seller Posting of Transmission Services

Sellers shall use the following Templates for providing sell information. They may aggregate portions of several

previous purchased to create a new service, if this capability is provided by the Transmission Services Information

Provider:
38980 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

4.3.8.1 Seller Capacity Posting (transpost)

Seller Capacity Posting (Input) (transpost) shall be used by the Seller to post the transmission capacity for resale

on to the OASIS Node.

SELLERlCODE and SELLERlDUNS shall be determined from the registered connection used to input the request.

Template: transpost

1. Input

PATHlNAME

POINTlOFlRECEIPT

POINTlOFlDELIVERY

INTERFACElTYPE

CAPACITY

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlWINDOW

TSlSUBCLASS

OTHERlCURTAILMENTlPRIORITY (optional)

ANClSVClREQ

STARTlTIME

STOPlTIME

OFFERlSTARTlTIME

OFFERlSTOPlTIME

SALElREF

OFFERlPRICE

SERVICElDESCRIPTION

SELLERlCOMMENTS

2. Response (acknowledgement)

RECORDlSTATUS

POSTINGlREF (Assigned by TSIP)

PATHlNAME

POINTlOFlRECEIPT

POINTlOFlDELIVERY

INTERFACElTYPE

CAPACITY

SERVICElINCREMENT

TSlCLASS

TSlTYPE

TSlPERIOD

TSlWINDOW

TSlSUBCLASS

OTHERlCURTAILMENTlPRIORITY

ANClSVClREQ

STARTlTIME

STOPlTIME

OFFERlSTARTlTIME

OFFERlSTOPlTIME

SALElREF

OFFERlPRICE

SERVICElDESCRIPTION

SELLERlCOMMENTS

ERRORlMESSAGE

4.3.8.2 Seller Capacity Modify (transupdate)

Seller Capacity Modify (Input) (transupdate) shall be used by a Seller to modify a posting of transmission capacity.

SELLERlCODE and SELLERlDUNS shall be determined from the registered connection used to input the request.

Template: transupdate

1. Input

POSTINGlREF (Must be provided)

CAPACITY (only if modified)

STARTlTIME (only if modified)

STOPlTIME (only if modified)

OFFERlSTARTlTIME (only if modified)

OFFERlSTOPlTIME (only if modified)
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38981

ANClSVClREQ (only if modified)

SALElREF (only if modified)

OFFERlPRICE (only if modified)

SERVICElDESCRIPTION (only if modified)

SELLERlCOMMENTS (only if modified)

2. Response (acknowledgment)

RECORDlSTATUS

POSTINGlREF

CAPACITY

STARTlTIME

STOPlTIME

OFFERlSTARTlTIME

OFFERlSTOPlTIME

ANClSVClREQ

SALElREF

OFFERlPRICE

SERVICElDESCRIPTION

SELLERlCOMMENTS

ERRORlMESSAGE

4.3.9 Purchase of Ancillary Services

4.3.9.1 Customer Requests to Purchase Ancillary Services (ancrequest)

Customer Requests to Purchase Ancillary Services (ancrequest) (Input, Template Upload) is used by the customer

to purchase ancillary services that have been posted by a seller of those services. The same requirements exist for

the use of STATUSlNOTIFICATION as for transrequest. The reference Data Elements are optional.

CUSTOMERlCODE and CUSTOMERlDUNS shall be determined from the registered connection used to input the

request.

Template: ancrequest

1. Input

SELLERlCODE

SELLERlDUNS

CONTROLlAREA

CAPACITY

SERVICElINCREMENT

ANClSERVICElTYPE

STATUSlNOTIFICATION

STARTlTIME

STOPlTIME

BIDlPRICE

PRECONFIRMED

POSTINGlREF (Optionally set by Customer)

SALElREF (Optionally set by Customer)

REQUESTlREF (Optionally set by Customer)

DEALlREF (Optionally set by Customer)

CUSTOMERlCOMMENTS

2. Response (acknowledgement)

RECORDlSTATUS

ASSIGNMENTlREF (assigned by TSIP)

SELLERlCODE

SELLERlDUNS

CONTROLlAREA

CAPACITY

SERVICElINCRECMENT

ANClSERVICElTYPE

STATUSlNOTIFICATION

STARTlTIME

STOPlTIME

BIDlPRICE

PRECONFIRMED

POSTINGlREF

SALElREF

REQUESTlREF

DEALlREF

CUSTOMERlCOMMENTS
38982 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

ERRORlMESSAGE

4.3.9.2 Ancillary Services Status (ancstatus)

Ancillary Services Status (ancstatus) is used to provide the status of purchase requests regarding the ancillary services

that are available for sale by all Service Providers.

The AFFILIATElFLAG will be set by the TSIP to indicate whether or not the Customer is an affiliate of the

Seller.

The values of STATUS and processes for setting STATUS are the same as for transstatus.

Template: ancstatus

1. Query

SELLERlCODE*

SELLERlDUNS*

CUSTOMERlCODE*

CUSTOMERlDUNS*

CONTROLlAREA

SERVICElINCREMENT

ANClSERVICElTYPE

STATUS

STARTlTIME

STOPlTIME

STARTlTIMElQUEUED

STOPlTIMElQUEUED

ASSIGNMENTlREF

SALElREF

REQUESTlREF

DEALlREF

TIMElOFlLASTlUPDATE (only if TIMElOFlLASTlUPDATE is posted by record)

2. Response

ASSIGNMENTlREF

SELLERlCODE

SELLERlDUNS

CUSTOMERlCODE

CUSTOMERlDUNS

AFFILIATElFLAG (Set by TSIP)

CONTROLlAREA

CAPACITY

SERVICElINCREMENT

ANClSERVICElTYPE

STARTlTIME

STOPlTIME

CEILINGlPRICE

OFFERlPRICE

BIDlPRICE

PRECONFIRMED

POSTINGlREF

SALElREF

REQUESTlREF

DEALlREF

NEGOTIATEDlPRICElFLAG (‘‘L if Seller accepted Price is lower than OFFERlPRICE in ancoffering Template; ‘‘H’’

if higher; otherwise blank)

STATUS=QUEUED, RECEIVED, REBID, OFFER, ACCEPTED, REFUSED, CONFIRMED, WITHDRAWN, ANNULLED, RETRACTED

STATUSlNOTIFICATION

STATUSlCOMMENTS

TIMElQUEUED

RESPONSElTIMElLIMIT

TIMElOFlLASTlUPDATE

PRIMARYlPROVIDERlCOMMENTS

SELLERlCOMMENTS

CUSTOMERlCOMMENTS

SELLERlNAME

SELLERlPHONE

SELLERlFAX

SELLERlEMAIL

CUSTOMERlNAME

CUSTOMERlPHONE
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38983

CUSTOMERlFAX

CUSTOMERlEMAIL

4.3.9.3 Seller Approves Ancillary Service (ancsell)

Seller Approves Ancillary Service (ancsell) is used by the Seller to confirm acceptance after the Seller has approved

the purchase of ancillary service.

SELLERlCODE and SELLERlDUNS shall be determined from the registered connection used to input the request.

Template: ancsell

1. Input

ASSIGNMENTlREF

OFFERlPRICE

STATUS=RECEIVED, OFFER, ACCEPTED, REFUSED

STATUSlCOMMENTS

SELLERlCOMMENTS

2. Response (acknowledgment)

RECORDlSTATUS

ASSIGNMENTlREF

OFFERlPRICE

STATUS=RECEIVED, OFFER, ACCEPTED, REFUSED

STATUSlCOMMENTS

NEGOTIATEDlPRICElFLAG

RESPONSElTIMElLIMIT

SELLERlCOMMENTS

ERRORlMESSAGE

4.3.9.4 Customer accepts Ancillary Service (anccust)

Customer accepts Ancillary Service (anccust) is used by the customer to confirm acceptance after the seller has

approved the purchase of ancillary service.

The Customer must change the BIDlPRICE to be equal to the OFFERlPRICE before the STATUS can be set to

CONFIRMED.

CUSTOMERlCODE and CUSTOMERlDUNS shall be determined from the registered connection used to input the

request.

Template: anccust

1. Input

ASSIGNMENTlREF (Required)

REQUESTlREF

DEALlREF

BIDlPRICE

STATUS=REBID, CONFIRMED, WITHDRAWN

STATUSlCOMMENTS

STATUSlNOTIFICATION (If left blank, then the original URL from the ancrequest will be used)

CUSTOMERlCOMMENTS

2. Response (Acknowledgment)

RECORDlSTATUS

ASSIGNMENTlREF

REQUESTlREF

DEALlREF

BIDlPRICE

STATUS=REBID, CONFIRMED, WITHDRAWN

STATUSlCOMMENTS

STATUSlNOTIFICATION

CUSTOMERlCOMMENTS

ERRORlMESSAGE

4.3.10 Seller Posting of Ancillary Services

4.3.10.1 Seller Ancillary Services Posting (ancpost)

Seller Ancillary Services Posting (ancpost) is used by the Seller to post information regarding the different services

that are available for sale by third party Sellers of ancillary services.

SELLERlCODE and SELLERlDUNS shall be determined from the registered connection used to input the request.

Template: ancpost

1. Input

CONTROLlAREA
38984 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

SERVICElDESCRIPTION

CAPACITY

SERVICElINCREMENT

ANClSERVICElTYPE

STARTlTIME

STOPlTIME

OFFERlSTARTlTIME

OFFERlSTOPlTIME

SALElREF

OFFERlPRICE

SELLERlCOMMENTS

2. Response (acknowledgment)

RECORDlSTATUS

POSTINGlREF (Assigned by TSIP)

CONTROLlAREA

SERVICElDESCRIPTION

CAPACITY

SERVICElINCREMENT

ANClSERVICElTYPE

STARTlTIME

STOPlTIME

OFFERlSTARTlTIME

OFFERlSTOPlTIME

SALElREF

OFFERlPRICE

SELLERlCOMMENTS

ERRORlMESSAGE

4.3.10.2 Seller Modify Ancillary Services Posting (ancupdate)

Seller Modify Ancillary Services Posting (ancupdate) is used by the Seller to modify posted information regarding

ancillary services that are available for sale by a third party Seller.

SELLERlCODE and SELLERlDUNS shall be determined from the registered connection used to input the request.

Template: ancupdate

1. Input

POSTINGlREF (Required)

CAPACITY (only if modified)

SERVICElDESCRIPTION (only if modified)

STARTlTIME (only if modified)

STOPlTIME (only if modified)

OFFERlSTARTlTIME (only if modified)

OFFERlSTOPlTIME (only if modified)

SALElREF (only if modified)

OFFERlPRICE (only if modified)

SELLERlCOMMENTS (only if modified)

2. Response (acknowledgment)

RECORDlSTATUS

POSTINGlREF

CAPACITY

SERVICElDESCRIPTION

STARTlTIME

STOPlTIME

OFFERlSTARTlTIME

OFFERlSTOPlTIME

SALElREF

OFFERlPRICE

SELLERlCOMMENTS

ERRORlMESSAGE

4.3.11 Informal Messages

4.3.11.1 Provider/Customer Want Ads and Informal Message Posting Request (messagepost)

Provider/Customer Want Ads and Informal Message Posting Request (messagepost) is used by Providers and Customers

who wish to post a message. The valid entries for CATEGORY shall be defined by providers and shall be listed

in the List of CATEGORY Template.

One CATEGORY shall be DISCOUNT. All discount prices accepted by a Customer shall be immediately posted

as a message using the DISCOUNT CATEGORY. This will permit carry-over from Phase I.
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38985

CATEGORYlCODE and CUSTOMERlDUNS shall be determined from the registered connection used to input the

request.

Template: messagepost

1. Input

SUBJECT

CATEGORY

VALIDlFROMlTIME

VALIDlTOlTIME

MESSAGE (must be specified)

2. Response (acknowledgment)

RECORDlSTATUS

POSTINGlREF (assigned by information provider)

SUBJECT

CATEGORY

VALIDlFROMlTIME

VALIDlTOlTIME

MESSAGE

ERRORlMESSAGE

4.3.11.2 Message (message)

Message (message) is used to view a posted Want Ad or Informal Message. The CATEGORY data element can

be queried. Specifically it shall be possible to query for the CATEGORY of DISCOUNT. This will permit carry-over

from Phase 1.

Template: message

1. Query

CUSTOMERlCODE

CUSTOMERlDUNS

POSTINGlREF

CATEGORY

VALIDlFROMlTIME

VALIDlTOlTIME

TIMElPOSTED

2. Response

CUSTOMERlCODE

CUSTOMERlDUNS

POSTINGlREF

SUBJECT

CATEGORY

VALIDlFROMlTIME

VALIDlTOlTIME

TIMElPOSTED

CUSTOMERlNAME

CUSTOMERlPHONE

CUSTOMERlFAX

CUSTOMERlEMAIL

MESSAGE

4.3.11.3 Provider/Sellers Message Delete Request (messagedelete)

Providers/Sellers Message Delete Request (messagedelete) is used by Providers and Sellers who wish to delete their

message. POSTINGlREF number is used to determine which message.

CUSTOMERlCODE AND CUSTOMERlDUNS shall be determined from the registered connection used to input

the request.

Template: messagedelete

1. Input

POSTINGlREF

2. Response (acknowledgment)

RECORDlSTATUS

POSTINGlREF

ERRORlMESSAGE

4.3.11.4 Personnel Transfers (personnel)

Template: personnel

1. Query

TIMElOFlLASTlUPDATE
38986 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

STARTlTIMElPOSTED

STOPlTIMElPOSTED

2. Response

POSTINGlNAME

EMPLOYEElNAME

FORMERlPOSITION

FORMERlCOMPANY

FORMERlDEPARTMENT

NEWlPOSITION

NEWlCOMPANY

NEWlDEPARTMENT

DATElTIMElEFFECTIVE

DATElTIMElPOSTED

TIMElOFlLASTlUPDATE

4.3.11.5 Discretion (discretion)

Template: discretion

1. Query

STARTlTIMElPOSTED

STOPlTIMElPOSTED

STARTlTIME

STOPlTIME

SERVICElTYPE

SERVICElNAME

TIMElOFlLASTlUPDATE

2. Response

POSTINGlNAME

RESPONSIBLElPARTYlNAME (name of person granting discretion)

SERVICElTYPE (ancillary or transmission)

SERVICElNAME (make consistent with offering Templates)

TARIFFlREFERENCE

STARTlTIME

STOPlTIME

DISCRETIONlDESCRIPTION

TIMElPOSTED

TIMElOFlLASTlUPDATE

4.3.11.6 Standards of Conduct (stdconduct)

Template: stdconduct

1. Query

STARTlTIMElPOSTED

STOPlTIMElPOSTED

TIMElOFlLASTlUPDATE

2. Response

POSTINGlNAME

RESPONSIBLElPARTYlNAME

STANDARDSlOFlCONDUCTlISSUES

TIMElPOSTED

TIMElOFlLASTlUPDATE

4.4 File Request and File Download Examples

4.4.1 File Example for Hourly Offering

Example of the request to Primary Provider, aaa, and response for Seller, wxyz, for PATHlNAME ‘‘W/AAAA/

PATHlABC//’’ for April 10, 1996 from 8 a.m. to 3 p.m. (Note that the PATHlNAME consists of a REGIONlCODE,

PRIMARYlPROVIDERlCODE, PATHlCODE, and an OPTIONALlCODE, separated with a slash, ‘‘/’’.) The VERSION

for Phase 1A is 1.2.

The request is in the form of a URL query string and the response is a ASCII delimited file.

1. Query

http://(OASIS Node name)/OASIS/aaa/data/ transoffering? ver=1.2&templ=transoffering& fmt=data&pprov=AAAA

&pprovduns= 123456789& path=W/AAA/ABC// &seller=WXYZAA &sellerduns=987654321& POR=aaa& POD=bbb&

servincre=hourly& TSCLASS1=firm &TSCLASS2=non-firm&tz=PD&stime=19960410080000PD&sptime=19960410150000PD

2. Response Data

REQUEST-STATUS=200↵(Successful)
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38987

TIMElSTAMP=19960409113526PD↵

VERSION=1.2↵

TEMPLATE=transoffering↵

OUTPUTlFORMAT=DATA↵

PRIMARYlPROVIDERlCODE=AAAA↵

PRIMARYlPROVIDERlDUNS=123456789↵

DATAlROWS=14↵

COLUMNlHEADERS= TIMElOFlLASTlUPDATE, SELLERlCODE, SELLERlDUNS, PATHlNAME,

POINTlOFlRECEIPT, POINTlOFlDELIVERY, INTERFACElTYPE, OFFERlSTARTlTIME, OFFERlSTOPlTIME,

STARTlTIME,STOPlTIME, CAPACITY, SERVICElINCREMENT, TSlCLASS,TSlTYPE, TSlPERIOD, TSlSUBCLASS,

SALElREF, POSTINGlREF, CEILINGlPRICE, OFFERlPRICE, PRICElUNITS, SERVICElDESCRIPTION, SELLERlNAME, SELLERlPHONE, SELLERlFAX, SELLERlEMAIL, SELLERlCOMMENTS↵

19960409030000PD, WXYZ, 987654321, W/AAA/ABC//,N/A,N/A,E, 19960402080000PD, 19960410080000PD,

19960410080000PD,19960410090000PD,300, HOURLY, FIRM, POINTlTOlPOINT, OFFlPEAK, N/A, N/A, A001,

1.50,1.35,MW,N/A,N/A,N/A,N/A,N/A,10% DISCOUNT↵

19960409030000PD,WXYZ,987654321,W/AAA/ABC//,N/A,N/A,E,19960402080000PD,19960410080000PD,

1960410080000PD, 19960410090000PD,300, HOURLY, NON-FIRM, POINTlTOlPOINT, OFFlPEAK, N/A,N/A,A001.50,

1.35,MW,N/A,N/A,N/A,N/A,N/A, 10% DISCOUNT↵

19960409030000PD, WXYZ, 987654321,W/AAA/ABC//,N/A,N/A,E, 19960402080000PD, 19960410080000PD,

19960410090000PD, 1996041010000PD,300, HOURLY, FIRM, POINTlTOlPOINT, OFFlPEAK, N/A,N/A,A001,1.50,1.35,

MW,N/A,N/A,N/A,N/A,N/A,10% DISCOUNT↵

19960409030000PD, WXYZ, 987654321,W/AAA/ABC//,N/A,N/A,E, 19960402080000PD, 19960410080000PD,

19960410090000PD, 19960410100000PD,300, HOURLY, NON-FIRM, POINTlTOlPOINT, OFFlPEAK, N/A,N/

A,A001,1.50,1.35.MW, N/A,N/A,N/A,N/A,N/A, 10% DISCOUNT↵

19960409030000PD, WXYZ. 987654321,W/AAA/ABC//,N/A,N/A,E, 19960402080000PD,

19960410080000PD,19960410100000PD,19960410110000PD,300, HOURLY, FIRM, POINTlTOlPOINT, OFFlPEAK, N/

A,N/A,A001,1.50,1.35,MW,N/A,N/A,N/A,N/A,N/A,10% DISCOUNT↵

19960409030000PD, WXYZ, 987654321,W/AAA/ABC//,N/A,N/A,E, 19960402080000PD, 19960410080000PD,

19960410100000PD, 19960410110000PD,300, HOURLY, NON-FIRM, POINTlTOlPOINT, OFFlPEAK, N/A,N/

A,A001,1.50,1.35,MW,N/A,N/A,N/A,N/A,N/A, 10% DISCOUNT↵

19960409030000PD, WXYZ, 987654321,W/AAA/ABC//,N/A,N/A,E, 19960402080000PD,

19960410080000PD,19960410110000PD,19960410120000PD,300, HOURLY, FIRM, POINTlTOlPOINT, OFFlPEAK, N/

A,N/A,A001,1.50,1.35,MW,N/A,N/A,N/A,N/A,10% DISCOUNT↵

19960409030000PD, WXYZ, 98765321,W/AAA/ABC//,N/A,N/A,E, 19960402080000PD, 19960410080000PD,

19960410110000PD,19960410120000PD,300, HOURLY, NON-FIRM, POINTlTOlPOINT, OFFlPEAK, N/A,N/

A,A001,1.50,1.35,MW,N/A,N/A,N/A,N/A,N/A, 10% DISCOUNT↵

. . .

. . .

. . .

19960409030000PD, WXYZ, 987654321,W/AAA/ABC//,N/A,N/A,E, 19960402080000PD, 19960410080000PD,

19960410140000PD,19960410150000PD,300, HOURLY, FIRM, POINTlTOlPOINT, OFFlPEAK, N/A,N/

A,A001,1.50,1.35,MW,N/A,N/A,N/A,N/A,N/A,10% DISCOUNT↵

1996040903000PD, WXYZ, 987654321,W/AAA/ABC//,N/A,N/A,E, 1996040208000PD, 19960410080000PD,

1996041014000PD,19960410150000PD,300, HOURLY, NON-FIRM, POINTlTOlPOINT, OFFlPEAK, N/A,N/

A,A001,1.50,1.35,MW,N/A,N/A,N/A,N/A,N/A, 10% DISCOUNT↵

4.4.2 File Example for Hourly Schedule Data

This example shows a request for the hourly schedule data from Primary Provider, aaa, related to the seller, wxyz,

for the period 10 a.m. to 3 p.m. on April 10, 1996.

There are two identical requests examples using two slightly different methods. The first request is using a HTTP

URL request string through an HTML GET method. The second request is a similar example using fetchlhttp from

a file using a POST method.

1. Query

URL Request (HTTP method=GET)

http://(OASIS Node name)/OASIS/aaa/data/schedule? ver=1.0& pprov=AAAA& templ=schedule& fmt=data

&pprovduns=123456789 &path=W/AAA/ABC//& seller=WXYZ &por=BBB &pod=CCC&tz=PD& stime=19960410100000PD&

sptime=19960410150000PD

URL Request (HTTP method=POST)

$ fetchlhttp http://(OASIS Node name)/OASIS/aaa/data/OASISdata -f c:/OASIS/wxyz/upload/in-file.txt

Where in-file.txt contains the following:

ver=1.0& pprov=AAAA& templ=schedule& fmt=data &pprovduns=123456789 &path=W/AAA/ABC//& seller=WXYZ

&por=BBB &pod=CCC& tz=PD& stime=19960410100000PD& sptime=19960410150000PD

2. Response Data

REQUEST-STATUS=200↵

TIMElSTAMP=1996041014702PD↵
38988 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

VERSION=1.2↵

TEMPLATE=Schedule↵

OUTPUTlFORMAT=DATA↵

PRIMARYlPROVIDERlCODE=AAAA↵

PRIMARYlPROVIDERlDUNS=123456789↵

DATAlROWS=5↵

COLUMNlHEADERS=TIMElOFlLASTlUPDATE, SELLERlCODE, SELLERlDUNS, PATHlNAME,

POINTlOFlRECEIPT, POINTlOFlDELIVERY, CUSTOMERlCODE, CUSTOMERlDUNS, AFFILIATElFLAG,

STARTlTIME, STOPlTIME, CAPACITY, CAPACITYlSCHEDULED, SERVICElINCREMENT, TSlCLASS, TSlTYPE,

TSlPERIOD, TSlSUBCLASS, ASSIGNMENTlREF↵

19960409030000pd. wxyz, 0987654321,W/AAA/ABC//, BBB,CCC, WXYZAA,0987654322,Y, 19960410100000PD,

19960410110000PD,300,300, HOURLY, FIRM, POINTlTOlPOINT, OFFlPEAK, N/A 856743↵

. . .↵

. . .↵

19960409030000pd, wxyz, 0987654321,W/AAA/ABC//,BBB,CCC, WXYZAA, 0987654322,Y,

19960410130000PD,19960410140000PD,300,300, HOURLY, FIRM, POINTlTOlPOINT, OFFlPEAK, N/A. 856743↵

19960409030000pd, wxyz, 0987654321,W/AAA/ABC//,BBB, CCC,WXYZAA, 0987654322,Y, 19960410140000PD,

19960410150000PD, 303,300.HOURLY,FIRM,POINTlTOlPOINT,OFFlPEAK,N/A, 856743↵

4.4.3 Customer Posting a Transmission Service Offering

This example shows how a Customer would post for sale the transmission service that was purchased perviously.

The Seller would create a file and upload the file using the FETCHlHTTP program to send a file to the OASIS

node of the Primary Provider.

1. Input

VERSION=1.2↵

TEMPLATE=transpost↵

OUTPUTlFORMAT=DATE↵

PRIMARYlPROVIDERlCODE=AAAA↵

PRIMARYlPROVIDERlDUNS=123456789↵

DATAlROWS=1↵

COLUMNlHEADERS=PATHlNAME, POINTlOFlRECEIPT, POINTlOFlDELIVERY, INTERFACElTYPE, CAPACITY,

SERVICElINCREMENT, TSlCLASS, TSlTYPE, TSlPERIOD, TSlSUBCLASS, STARTlTIME, STOPlTIME,

OFFERlSTARTlTIME, OFFERlSTOPlTIME, SALElREF, OFFERlPRICE, SERVICElDESCRIPTION, SELLERlCOMMENTPF↵

WXYZ,987654321, W/AAA/ABC//, N/A,N/A,E,150, HOURLY, FIRM, POINTlTOlPOINT, OFFlPEAK, N/

A..19960402080000PD, 19960410080000PD, 19960410080000PD, 19960410150000PD, A123,.90.,N/A,‘‘‘‘As Joe said, ‘‘It is

a good buy’’’’’’↵

FETCHlHTTP Command to spend posting

$fetchlhttp http://(OSASIS Node name)/OASIS/abcd/data/transrequest -fc:/OASIS/abcd/upload/post.txt

2. Response Data

REQUEST-STATUS=200↵ (Successful)

TIMElSTAMP=19960409113526PD↵

VERSION-1.2↵

TEMPLATE=Transport↵

OUTPUTlFORMAT=DATA↵

PRIMARYlPROVIDERlCODE=AAAA↵

PRIMARYlPROVIDERlDUNS=1234456789↵

DATAlROWS=1↵

COLUMNlHEADERS=RECORDlSTATUS, PATHlNAME, POINTlOFlRECEIPT, POINTlORlDELIVERY, INTERFACElTYPE, CAPACITY, SERVICElINCREMENT, TSlCLASS, TSlTYPE, TSlPERIOD, TSlSUBCLASS,

STARTlTIME, STOPlTIME, OFFERlSTARTlTIME, OFFERlSTOPlTIME, SALElREF, OFFERlPRICE, SERVICElDESCRIPTION, SELLERlCOMMENTS, ERRORlMESSAGE↵

200,WXYZ, 987654321, W/AAA/ABC//,N/A,NA,E,150, HOURLY, FIRM, POINTlTOlPOINT, OFFlPEAK, N/

A,19960402080000PD, 19960410080000PD, 19960410080000PD, 19960410150000PD, A123..90,N/A,‘‘As Joe said, ‘‘‘‘It is

a good buy’’’’’’, NO ERROR↵

4.4.4 Example of Re-aggregating Purchasing Services Using Reassignment

The following examples do not show the complete Template information, but only show those elements of the

Template of interest to the example.

a. Customer #1, ‘‘BestE’’ requests the purchase of 150 MW Firm ATC for 8 a.m. to 5 p.m. for $1.00 from a Primary

Provider (transrequest).

TEMPLATE=transrequest↵

CUSTOMERlCODE=BestE↵

CAPACITY=150↵

TSlCLASS=‘‘FIRM’’↵
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38989

START TIME=‘‘1996050708000000PD’’↵

STOPlTIME=‘‘1996050717000000PD’’↵

BIDlPRICE=‘‘$1.00’’↵

The Information Provider assigns ASSIGNMENTlREF = 5000 on acknowledgment.

b. Customer #1 purchases 120 MW ATC Non-firm for 3 p.m. to 9 p.m. for $.90 (transrequest). The Information

Provider assigns the ASSIGNMENTlREF=5001 when the request for purchase is made and is shown in the acknowledgment.

TEMPLATE=‘‘transrequest’’↵

CUSTOMERlCODE=‘‘BestE’’↵

CAPACITY=120↵

TSlCLASS=‘‘NON-FIRM’’↵

STARTlTIME=‘‘1996050715000000PD’’↵

STOPlTIME=‘‘1996050721000000PD’’↵

BIDlPRICE=‘‘$1.05’’↵

c. Customer #1 becomes Seller #1 and post the Transmission service of 100 MW ATC Non-firm capacity from

8 a.m. to 9 p.m. for resale at $.90/MW-hour.

TEMPLATE=‘‘transpost’’↵

SELLERlCODE=‘‘BestE’’↵

CAPACITY=100↵

TSlCLASS=‘‘NON-FIRM’’↵

STARTlTIME=‘‘1996050708000000PD’’↵

STOPlTIME=‘‘1996050721000000PD’’↵

SALElREF=‘‘BEST100’’↵

OFFERlPRICE=.90↵

SELLERlCOMMENTS-‘‘aggregating two previous purchases’’↵

d. Customer #2 then requsts purchase of 100 MW Non-firm from Reseller #1 from 8 a.m. to 6 p.m. for $0.90/

MW=hour (transrequest).

TEMPLATE=‘‘transrequest’’↵

CUSTOMERlCODE=‘‘Whisle’’↵

SELLERlCODE=‘‘BestE’’↵

CAPACITYl=100↵

TSlCLASS=‘‘NON-FIRM’’↵

STARTlTIME=‘‘1996050708000000PD’’↵

STOPlTIME=‘‘1996050721000000PD’’↵

SALElREF=‘‘BEST100’’↵

DEALlREF=‘‘WPC100’’↵

BIDlPRICE=.90↵

CUSTOMERlCOMMENTS=‘‘Only need service until 6 p.m.’’↵

The Information Provider provides the ASSIGNMENTlREF=5002 for this transaction.

e. Seller informs the Information Provider of the reassignment of the previous transmission rights when the seller

accepts the customer purchase request (transsell).

TEMPLATE=‘‘transsell’’↵

CUSTOMERlCODE=‘‘Whisle’’↵

SELLERlCODE=‘‘BestE’’↵

ASSIGNMENTlREF=5002↵

STATUS=‘‘Accepted’’↵

REASSIGNEDlREFI=5000↵

REASSIGNEDlCAPACITY1=100↵

REASSIGNEDlSTARTlTIME1=‘‘199605070800PD’’↵

REASSIGNEDlSTOPlTIME1=‘‘199605071700PD’’↵

REASSIGNEDlREF2=5001↵

REASSIGNEDlCAPACITY2=100↵

REASSIGNEDlSTARTlTIME2=‘‘199605071700PD’’↵

REASSIGNEDlSTOPlTIME2=‘‘199605071800PD’’↵

4.4.5 File Examples of the Use of Continuation Records

a. Basic Continuation Records: The first example of the use of Continuation Records is for the transrequest Template

submitted by a Seller for purchase of a transmission reservation spanning 16 hours from 06:00 to 22:00 with ‘‘ramped’’

demand at beginning and end of time period. Two additional reservations appear prior to and following the profile

to demonstrate the handling of ASSIGNMENTlREF by the OASIS node.

Only the following fields may be redefined in a continuation record for the transrequest Template: CAPACITY,

STARTlTIME, STOPlTIME. Specification of any values corresponding to COLUMNlHEADERs other than CAPACITY,

STARTlTIME, and STOPlTIME will be ignored, however commas must be included to properly align the CAPACITY,

STARTlTIME and STOPlTIME fields.

Input:

VERSION=1.2↵

TEMPLATE=transrequest↵
38990 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

OUTPUTlFORMAT=DATA↵

PRIMARYlPROVIDERlCODE=AEP↵

PRIMARYlPROVIDERlDUNS=123456789↵

DATAlROWS=7↵

COLUMNlHEADERS=CONTINUATIONlFLAG, SELLERlCODE, SELLERlDUNS, PATHlNAME,

POINTlOFlRECEIPT, POINTlOFlDELIVERY, SOURCE, SINK, CAPACITY, SERVICElINCREMENT, TSlCLASS,

TSlTYPE, TSlPERIOD, TSlSUBCLASS, STATUSlNOTIFICATION, STARTlTIME, STOPlTIME, BIDlPRICE,

PRECONFIRMED, ANClSVClLINK, POSTINGlREF, SALElREF, REQUESTlREF, DEALlREF, CUSTOMERlCOMMENTS↵

N. AEP, 123456789, ABC/XY, CE, MECS...35, DAILY, FIRM, POINTlTOlPOINT, OFFlPEAK, N/A,,pub/AEP/incoming,

19970423000000ES, 19970424000000ES, 24.50, Y, SC:(cust:SP);RF(cust:RQ); EI:(cust:R123); SP:(custR234); SU:(cust:R345),

P0123, S123, R765, D123, Standard daily reservation↵

N, AEP, 123456789, ABC/XY, CE, AMPO,,,5, HOURLY, NON-FIRM, POINTlTOlPOINT, OFFlPEAK, N/A, pub/AEP/

incoming, 19970423060000ES, 19970423070000ES, 2.50, Y,SC:(cust:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123);

SP:(custR234); SU:(cust:R345), P0123, S123, R765, D123, First piece of profile spanning 5 records↵

Y,,,,,,,, 10,,,,,,, 19970423070000ES, 19970423080000ES,,,,,,,,Second piece↵

Y,,,,,,,, 15,,,,,,, 19970423080000ES, 19970423200000ES,,,,,,,,Third piece↵

Y,,,,,,,, 10,,,,,,, 19970423200000ES, 19970423210000ES,,,,,,,,Fourth piece↵

Y,,,,,,,, 5,,,,,,, 19970423210000ES, 19970423220000ES,,,,,,,,Fifth piece↵

N, AEP, 123456789, ABC/XY, CE, MECS,,, 20, HOURLY, FIRM, POINTlTOlPOINT, OFFlPEAK, N/A, pub/AEP/incoming, 19970423040000ES, 19970423220000ES, 2.00, Y,SC:(cust:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123); SP:(custR234);

SU:(cust:R345), P0123, S123, R765, D123, Standard hourly reservation after profiled reservation↵

Response:

REQUESTlSTATUS=200↵

TIMElSTAMP=19970422160523ES↵

TEMPLATE=transrequest↵

OUTPUTlFORMAT=DATA↵

PRIMARYlPROVIDERlCODE=AEP↵

PRIMARYlPROVIDERlDUNS=123456789↵

DATAlROWS=7↵

COLUMNlHEADERS=RECORDlSTATUS, CONTINUATIONlFLAG, SELLERlCODE, SELLERlDUNS, PATHlNAME,

POINTlOFlRECEIPT, POINTlOFlDELIVERY, SOURCE, SINK, CAPACITY, SERVICElINCREMENT, TSlTYPE,

TSlPERIOD, TSlSUBLCASS, STATUSlNOTIFICATION, STARTlTIME, STOPlTIME, BIDlPRICE, PRECONFIRMED,

ANClSVClLINK, POSTINGlREF, SALElREF, REQUESTlREF, DEALlREF, CUSTOMERlCOMMENTS,

ERRORlMESSAGE↵

200, N, AEP, 123456789, ABC/XY, CE, MECS,,,35, DAILY, FIRM, POINTlTOlPOINT, OFFlPEAK, N/A, pub/AEP/

incoming, 199702423000000ES, 19970424000000ES, 24.50, Y,SC:(cust:SP);RV:(cust:SP);RF(cust:RQ);EI:(cust:R123);

SP:(custR234); SU:(cust:R345), PO123, S123, R765, D123, Standard daily reservation, No error↵

200, N, AEP, 123456789, ABC/XY, CE, AMPO,,,5, HOURLY, NON-FIRM, POINTlTOlPOINT, OFFlPEAK, N/A, pub/

AEP/incoming, 199702423060000ES, 19970423070000ES, 2.50, Y,SC:(cust:SP); RV:(cust:SP);RF(cust:RQ);EI:(cust:R123);

SP:(custR234); SU;(cust:R345), P0123, S123, R765, D123, First piece of profile spanning 5 records, No error↵

200, Y,,,,,,,, 10,,,,,,,19970423070000ES, 19970423080000ES,,,,,,,,,Second piece, No error↵

200, Y,,,,,,,, 15,,,,,,,19970423080000ES, 199704232800000ES,,,,,,,,,Third piece, No error↵

200, Y,,,,,,,, 10,,,,,,,19970423200000ES, 19970423210000ES,,,,,,,,,Fourth piece, No error↵

200, Y,,,,,,,, 5,,,,,,,19970423210000ES, 19970423220000ES,,,,,,,,,Fifth piece, No error↵

200, N, AEP, 123456789, ABC/XY, CE, MECS,,,20, HOURLY, FIRM, POINTlTOlPOINT, OFFlPEAK, N/A, pub/AEP/

incoming, 19970423040000ES, 19970423160000ES, 2.00, Y, SC:(cust:SP);RV:(cust:SP);RF(cust:RQ);EI:(cust:R123);

SP:(custR234); SU:(cust:R345), P0123, S123, R765, D123, Standard hourly reservation after profiled reservation, No error↵

b. Submission of Reassignment Information—Case 1: In the prior example, a reservation request was submitted to

‘‘Rseler’’ for 20MW of Hourly Non-firm service from 04:00 to 16:00. Assume that Rseler has previously reserved service

for the CE-VP path for Daily Firm in amount of 50 MW on 4/23 under ASSIGNMENTlREF=7019, and Hourly NonFirm in amount of 10 MW from 08:00 to 20:00 on 4/23 under ASSIGNMENTlREF=7880. Rseler must designate which

transmission service rights are to be reassigned to Cust to satisfy the 20MW from 04:00 to 16:00. This reassignment

information is conveyed by Rseler using the transsell Template when the reservation request is ACCEPTED. At the

SELLER’s discretion, rights are assigned from the Non-firm reservation first (ASSIGNMENTlREF=7880) with the balance

taken up by the Firm reservation (ASSIGNMENTlREF=7019).

The only fields allowed in ‘‘continuation’’ records for transsell Template are REASSIGNEDlREF, REASSIGNEDlCAPACITY, REASSIGNEDlSTARTlTIME, and REASSIGNEDlSTOPlTIME. Price may not be negotiated for

each ‘‘segment’’ in a capacity profile.

Input:

VERSION=1.2↵

TEMPLATE=transsell↵

OUTPUTlFORMAT=DATA↵

PRIMARYlPROVIDERlCODE=AEP↵

PRIMARYlPROVIDERlDUNS=123456789↵

DATAlROWS=3↵

COLUMNlHEADERS=CONTINUATIONlFLAG, ASSIGNMENTlREF, OFFERlPRICE, STATUS, STATUSlCOMMENTS,

ANClSVClLINK, SELLERlCOMMENTS, REASSIGNEDlREF REASSIGNEDlCAPACITY, REASSIGNEDlSTARTlTI
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38991

SIGNEDlSTOPlTIME N. 8236, 2.00, ACCEPTED, Status comments

here,SC:(cust:SP);RV;(cust:SP);RF(cust:RQ);EI:(cust:R123);SP:(custR234);SU:(cust:R345), Seller comments here, 7019, 20,

19970423040000ES, 19970423080000ES↵

Y,,,,,,,7880, 10, 19970423080000ES, 19970423160000ES↵

Y,,,,,,,7019, 10, 19970423080000ES, 19970423160000ES↵

Response:

VERSION=1.2↵

TEMPLATE=transsell↵

OUTPUTlFORMAT=DATA↵

PRIMARYlPROVIDERlCODE=AEP↵

PRIMARYlPROVIDERlDUNS=123456789↵

DATAlROWS=3↵

COLUMNlHEADERS=RECORDlSTATUS, CONTINUATIONlFLAG, ASSIGNMENTlREF, OFFERlPRICE, STATUS,

STATUSlCOMMENTS, ANClSVClLINK, SELLERlCOMMENTS, REASSIGNEDlREF, REASSIGNEDlCAPACITY, REASSIGNEDlSTARTlTIME, REASSIGNEDlSTOPlTIME, ERRORlMESSAGES 200, N. 8236, 2.00, ACCEPTED, Status

comments here,SC:(cust:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123); SP:(cust:R234);SU:(cust:R345), Seller comments here,

7019, 20, 19970423040000ES, 19970423080000ES.↵

200 Y,,,,,,,7880, 10, 19970423080000ES, 19970423160000ES,↵

200 Y,,,,,,,7019, 10, 19970423080000ES, 19970423160000ES,↵

c. Submission of Reassignment Information—Case 2: Primary provider, AEP, is notified of a sale/assignment of transmission service right from ‘‘Resell’’ to ‘‘cust’’. The parameters of the new reservation are for 10MW on 4/23 for ‘‘offpeak’’ hours (00:00–06:00 and 22:00–24:00) on POR/POD CE–VP. Rseler is assigning rights to 10MW from a prior reservation for the CE–VP path for Daily Firm in amount of 50 MW on 4/23 under ASSIGNMENTlREF=7019 to Cust. AEP

would submit the following information using the transassign Template to post this (re)sale. The only fields allowed

in ‘‘continuation’’ records for the transassign Template are CAPACITY, STARTlTIME, STOPlTIME, REASSIGNEDlREF,

REASSIGNEDlCAPACITY, REASSIGNEDlSTARTlTIME, and REASSIGNEDlSTOPlTIME.

Even though there is a one-to-one correspondence between the segments of the new reservations and the reassignment

of service from a prior reservation, it is entirely possible that a reservation spanning a single contiguous period would

require multiple continuation records to convey reassignment information, and vice versa.

Fields for CUSTOMERlNAME and SELLERlNAME were used to convey user names for subsequent resolution

of contact information from user registration.

Input:

VERSION=1.2↵

TEMPLATE=transassign↵

OUTPUTlFORMAT=DATA↵

PRIMARYlPROVIDERlCODE=AEP↵

PRIMARYlPROVIDERlDUNS=123456789↵

DATAlROWS=2↵

COLUMNlHEADERS=CONTINUATIONlFLAG, CUSTOMERlCODE, CUSTOMERlDUNS, PATHlNAME,

POINTlOFlRECEIPT, POINTlOFlDELIVERY, SOURCE, SINK, CAPACITY, SERVICElINCREMENT, TSlCLASS,

TSlTYPE, TSlPERIOD, TSlSUBCLASS, STARTlTIME, STOPlTIME, OFFERlPRICE, SALElREF, POSTINGlNAME,

REASSIGNEDlREF, REASSIGNEDlCAPACITY, REASSIGNEDlSTARTlTIME, REASSIGNEDlSTOPlTIME, SELLERlCOMMENTS↵

N, Resler, 456123789, Cust, 987654321, , CE, VP, , , 10, HOURLY, NON-FIRM, POINTlTOlPOINT, OFFlPEAK, N/

A, 19970423000000ES, 19970423060000ES, 2.00, Joe Smith, Jane Doe, N, 19970422121354ES, , 7019, 10,

19970423000000ES, 19970423060000ES, Seller comments go here↵

Y, , , , , , , , , , 10, , , , , , 19970423220000ES, 19970424000000ES, , , , , , , 7019, 10, 19970423220000ES,

19970424000000ES↵

Response:

REQUESTlSTATUS=200↵

TIMElSTAMP=19970422144520ES↵

VERSION=1.2↵

TEMPLATE=transassign↵

OUTPUTlFORMAT=DATA↵

PRIMARYlPROVIDERlCODE=AEP↵

PRIMARYlPROVIDERlDUNS=123456789↵

DATAlROWS=2↵

COLUMNlHEADERS=RECORDlSTATUS, CONTINUATIONlFLAG, ASSIGNMENTlREF, SELLERlCODE, SELLERlDUNS, CUSTOMERlCODE, CUSTOMERlDUNS, AFFILIATElFLAG, PATHlNAME, POINTlOFlRECEIPT,

POINTlOFlDELIVERY, SOURCE, SINK, CAPACITY, SERVICElINCREMENT, TSlCLASS, TSlTYPE, TSlPERIOD,

TSlSUBCLASS, STARTlTIME, STOPlTIME, OFFERlPRICE, SELLERlNAME, CUSTOMERlNAME, TIMElQUEUED,

SALElREF, REASSIGNEDlREF, REASSIGNEDlCAPACITY, REASSIGNEDlSTARTlTIME, REASSIGNEDlSTOPlTIME, SELLERlCOMMENTS, ERRORlMESSAGE↵

200, N, 8207, Rseler, 456123789, Cust, 987654321, N, , CE, VP, , , 10, HOURLY, FIRM, POINTlTOlPOINT, OFFlPEAK,

N/A 19970423000000ES, 19970423060000ES, 2.00, Joe Smith, Jane Doe, 19970422121354ES, , 7019, 10, 19970423000000ES,

19970423060000ES, Seller comments go here,↵
38992 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

200, Y, , , , , , , , , , , , 10, , , , , , 19970423220000ES, 19970424000000ES,,,,,, 7019, 10, 19970423220000ES,

19970424000000ES,,↵

d. Query of Transmission Reservation Status: The following typical response to a transstatus query might be delivered

for 4/23 based on prior examples. Note that the only fields returned in ‘‘continuation’’ records are, CAPACITY,

STARTlTIME, STOPlTIME, REASSIGNEDlREF, REASSIGNEDlCAPACITY, REASSIGNEDlSTARTlTIME, and REASSIGNEDlSTOPlTIME (price fields are debatable).

Input:

<appropriate query name/value pairs to return reservations for 4/23>

Response:

REQUESTlSTATUS=200↵

TIMElSTAMP=19970423040523ES↵

TEMPLATE-transstatus↵

OUTPUTlFORMAT=DATA↵

PRIMARYlPROVIDERlCODE=AEP↵

PRIMARYlPROVIDERlDUNS=123456789↵

DATAlROWS=11↵

COLUMNlHEADERS=CONTINUATIONlFLAG, ASSIGNMENTlREF, SELLERlCODE, SELLERlDUNS, CUSTOMERlCODE, CUSTOMERlDUNS, AFFILIATElFLAG, PATHlNAME, POINTlOFlRECEIPT,

POINTlOFlDELIVERY, SOURCE, SINK, CAPACITY, SERVICElINCREMENT, TSlCLASS, TSlTYPE, TSlPERIOD,

TSlSUBCLASS, STARTlTIME, STOPlTIME, CEILINGlPRICE, OFFERlPRICE, BIDlPRICE, PRECONFIRMED,

ANClSVClLINK, ALTERNATElSERVICElFLAG, POSTINGlREF, SALElREF, REQUESTlREF, DEALlREF, NEGOTIATEDlPRICElFLAG, STATUS, STATUSlCOMMENTS, TIMElQUEUED, TIMElOFlLASTlUPDATE, PRIMARYlPROVIDERlCOMMENTS, SELLERlCOMMENTS, CUSTOMERlCOMMENTS, SELLERlNAME, SELLERlPHONE, SELLERlFAX, SELLERlEMAIL, CUSOMTERlNAME, CUSTOMERlPHONE, CUSTOMERlFAX, CUSTOMERlEMAIL, REASSIGNEDlREF, REASSIGNED,lCAPACITY, REASSIGNEDlSTARTlTIME, REASSIGNEDlSTOPlTIME5

N, 8207, Rseler, 456123789, A Cust, 987654321, N, CE, VP, , , 10, HOURLY, FIRM, POINTlTOlPOINT, OFFlPEAK,

N/A, 19970423000000ES, 19970423060000ES, 2.25, 2.00, 6.20, N,SC:(cust:SP); RV:(cust:SP); RF(cust:RQ); EI:(cust:R123);

SP:(custR234); SU:(cust:R345), N, , , , , N, CONFIRMED, , 19970422121354ES,, TP Comments, Seller comments go

here, Customer comments, Joe Smith, (888)–123–4567, (888)–123–1231, jsmith@xyz.com, Jane Doe, (999)–123–4567, (999)–

123–8823, , 7019, 10, 19970423000000ES, 19970423060000ES↵

Y, , , , , , , , , , , , , 10, , , , , , 19970423220000ES, 19970424000000ES, , , , , , , , , , , , , , , , , , , , , ,7019,

10, 19970423220000ES, 19970424000000ES↵

N, 8234, Rseler, 456123789, ACust, 987654321, N, , CE, MECS, , , 35 DAILY, FIRM, POINTlTOlPOINT, OFFlPEAK,

N/A 19970423000000ES, 1997042360000ES, 42.00, 24,50, N,SC:(cust:SP); RV:(cust:SP); RES:(cust:RQ); EI:(cust:R123);

SP:(custR234);SU:(cust:R345),N, , , , , N, CONFIRMED, , 19970422121354ES, , Standard daily reservation, System Operator,

Customer comments, Frank Orth, (999)–123–4567, (999)–123–1231, jsmith@xyz.com, Jane Doe, (999)–123–4567, (999)–

123–8823, 7019, 10, 19970423000000ES, 19970423060000ES↵

N, 8235, AEP, 123456789, Cust, 987654321, N, , CE, AMPO, , , 5, HOURLY, NON-FORM, POINTlTOlPOINT;

OFFlPEAK, N/A, 19970423060000ES, 19970423070000ES, 2.50, 2.50, 6.20, N, SC:(cust:SP); RV:(cust:SP); RF(cust:RQ);

EI:(cust:R123); SP:(cust:R234); SU:(cust:R345),N, , , , , N, CONFIRMED, , 19970422160523ES, , Profile verified, First

piece, Customer comments, System Operator, (888)–123–4567, (888)–123–1231, jsmith@xyz.com, Jane Doe, (999)–123–

4567, (999)–123–8823,, 7019, 10, 19970423000000ES, 19970423060000ES↵

Y, , , , , , , , , , , , , 10, , , , , , ,19970423070000ES, 1997042380000ES, , , , , , , , , , , , , , , , , , , , , ,

, , ,↵

Y, , , , , , , , , , , , ,15, , , , , , ,19970423080000ES, 19970423200000ES, , , , , , , , , , , , , , , , , , , , , ,

, , ,↵

Y, , , , , , , , , , , , ,10, , , , , , ,19970423200000ES, 19970423210000ES, , , , , , , , , , , , , , , , , , , , , ,

, , ,↵

Y, , , , , , , , , , , , ,5, , , , , , ,19970421000000ES, 19970423220000ES, , , , , , , , , , , , , , , , , , , , , , ,

, ,↵

N. 8236, Rseler, 456123789, Cust, 987654321, N, , CE, VP, , , 20, HOURLY, FIRM, POINTlTOlPOINT, OFFlPEAK,

N/A 19970424040000ES, 19970424160000ES, 2.00, 2.50, 6.20, N, , , , , , CONFIRMED, , 19970422160523ES, , Bid

price refused, Negotiated OFFERlPRICE accepted, Joe Smith, (888)–123–4567, (888)–123–1231, jsmithxyz.com, Jane Doe,

(999)–123–4567, (999)–123–8823, 7019, 20, 19970423040000ES, 19970423080000ES↵

Y, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , 7880, 10, , , , , , 19970423080000ES, 19970423160000ES↵

Y, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , 7019, 10, , , , , , 19970423080000ES, 19970423160000ES↵

4.4.6 Example of Negotiation of Price

4.4.6.1 Negotiation with Preconfirmation

a. The Customer submits a PRECONFIRMED transmission service request using the transreqest Template. Initially,

the STATUS is set to QUEUED by OASIS.

b. The Seller has the option of setting STATUS via the transsell Template to one of the following: RECEIVED,

STUDY, ACCEPTED, or REFUSED. Since the request is PRECONFIRMED, the Seller is blocked from altering OFFERlPRICE

by OASIS, and blocked from setting status of OFFER.

c. If the Seller sets STATUS to ACCEPTED, OASIS will immediately set STATUS to CONFIRMED and sets the

OFFERlPRICE to the BIDlPRICE.
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38993

d. The Customer may WITHDRAW request via transcust Template at any time up to point where the Seller sets

STATUS to ACCEPTED.

e. Once the STATUS is CONFIRMED, the OFFERlPRICE officially becomes the terms of the reservation.

4.4.6.2 Negotiations without Preconfirmation

e. The Customer submits a transmission reservation request with the BIDlPRICE less than the CEILINGlPRICE

via the transrequest Template. Initially the STATUS is set to QUEUED by OASIS.

b. The Seller has the option of setting the STATUS VIA the transsell Template to one of the following: RECEIVED,

STUDY, ACCEPTED, OFFER, or REFUSED.

c. The Seller determines that the BIDlPRICE is too low, sets the OFFERlPRICE to the price he wants, and sets

the STATUS to OFFER via the transsell Template.

d. The Customer agrees to the OFFERlPRICE, sets the BIDlPRICE equal to the OFFERlPRICE, and sets the STATUS

to CONFIRMED via the transcust Template.

The OFFERlPRICE with the STATUST of CONFIRMED locks in the terms of the reservation.

4.4.6.3 Multiple Step Negotiations

a. The Customer submits a transmission reservation request with the BIDlPRICE less than the CEILINGlPRICE

via the transrequest Template. Initially the STATUS is set to QUEUED by OASIS.

b. The Seller has the option of setting STATUS via the transsell Template to one of the following: RECEIVED,

STUDY, ACCEPTED, OFFER, or REFUSED.

c. The Seller determines that the BIDlPRICE is too low, sets the OFFERlPRICE to the desired value, and sets

the STATUS to OFFER via the transsell Template.

d. The Customer responds to the new OFFERlPRICE with an updated BIDlPRICE and sets the STATUS to REBID

for re-evaluation by the Seller.

e. The Seller determines that the BIDlPRICE now is acceptable and sets the STATUS to ACCEPTED via the transsell

Template. The transition to ACCEPTED state requires the OFFERlPRICE to be set to the BIDlPRICE: accepting a

reservation with an OFFERlPRICE different from BIDlPRICE would require the STATUS be set to OFFER rather

than ACCEPTED (see item c).

f. The Customer agrees to the OFFERlPRICE and sets the STATUS to CONFIRM via the transcust Template.

g. The OFFERlPRICE with the STATUS as CONFIRMED locks in the terms of the reservation.

4.4.6.4 Negotiations Refused by Seller

a. The Customer submits a transmission reservation request with the BIDlPRICE less than the CEILINGlPRICE

via the transrequest Template. Initially the STATUS is set to QUEUED by OASIS.

b. The Seller has the option of setting the STATUS via the transsell Template to one of the following: RECEIVED,

STUDY, ACCEPTED, OFFER, or REFUSED.

c. The Seller determines that the BIDlPRICE is too low, sets OFFERlPRICE to his desired value, and sets STATUS

to OFFER via the transsell Template.

d. The Customer responds to OFFERlPRICE with updated BIDlPRICE and sets the STATUS to REBID via the

transcust Template for re-evaluation by Seller.

e. The Seller breaks off all further negotiations by setting the STATUS or REFUSED.

4.4.6.5 Negotiations Withdrawn by Customer

a. The Customer submits a transmission reservation request with the BIDlPRICE less than the CEILINGlPRICE

via the transrequest. Initially the STATUS is set to QUEUED by OASIS.

b. The Seller has the option of setting STATUS via the transsell Template to one of the following: RECEIVED,

STUDY, ACCEPTED, OFFER, or REFUSED.

c. The Seller determines that the BIDlPRICE is too low, sets the OFFERlPRICE to his desired value, and sets

the STATUS to OFFER via the transsell Template.

d. The Customer responds to the OFFERlPRICE with an updated BIDlPRICE and sets the STATUS to REBID

for re-evaluation by Seller.

e. The Seller determines that the BIDlPRICE is still too low, sets the OFFERlPRICE to another value, and sets

STATUS to OFFER via the transsell Template.

f. The Customer breaks off all further negotiations by setting STATUS to WITHDRAWN (or the customer/seller

could go through additional iterations of REBID/OFFER until negotiations are broken off or the reservation is CONFIRMED).

4.5 Information Supported by WEB Page

There shall be a Web page on each OASIS node with information on requesting the text file of the tariffs and

service agreements.

5. Performance Requirements

A critical aspect of any system is its performance. Performance encompasses many issues, such as security, sizing,

response to user requests, availability, backup, and other parameters that are critical for the system to function as

desired. The following sections cover the performance requirements for the OASIS.

5.1 Security

Breaches of security include many inadvertent or possibly even planned actions. Therefore, several requirements

shall be implemented by the TSIPs to avoid these problems:

a. Provider Update of TS Information: Only Providers, including Secondary Providers, shall be permitted to update

their own TS Information.
38994 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

b. Customer Input Only ASCII Text: TSIPs shall be permitted to require that inputs from Customers shall be filtered

to permit only strict ASCII text (strip bit 8 from each byte).

c. Provider Updating Over Public Facilities: If public facilities are involved in the connection between a Provider

and the OASIS Node, the Provider shall be able to update this TS Information only through the use of ASCII or

through encrypted files.

d. User Registration and Login: All Users shall be required to register and login to a Provider’s Account before

accessing that Provider’s TS Information.

e. User Passwords: All Users shall enter their personal password when they wish access to TS Information beyond

the lowest Access Privilege.

f. Service Request Transactions: Whenever Service Request transactions are implemented entirely over the OASIS,

both an individual Customer password for the request, and an individual Provider password for the notification of

acceptance shall be required.

g. Data Encryption: Sophisticated data encryption techniques and the ‘‘secure id’’ mechanisms being used on the

public Internet shall be used to transfer sensitive data across the Internet and directly between OASIS Nodes.

h. Viruses: Since only data is being transmitted between the OASIS Nodes and the Users, viruses are unlikely

to be passed between them. Therefore, TSIPs shall be responsible for ensuring that the OASIS Nodes are free from

viruses, but need not screen data exchanges with Users for viruses.

i. Performance Log: TSIPs shall keep a log on User usage of OASIS resources.

j. Disconnection: TSIPs shall be allowed to disconnect any User who is degrading the performance of the OASIS

Node through the excessive use of resources, beyond what is permitted in their Service Level Agreement.

k. Premature Access: The TSIP log shall also be used to ensure that Users who are affiliated with the Provider’s

company (or any other User) do not have access to TS information before it is publicly available.

l. Firewalls: TSIPs shall employ security measures such as firewalls to minimize the possibility that unauthorized

users shall access or modify TS Information or reach the Provider or User systems. Interfaces through Public Data

Networks or the Internet shall be permitted as long as these security requirements are met.

m. Certificates and Public Key Standards (optional): Use of alternative forms of login and authentication using

certificates and public key standards is acceptable.

5.2 Access Privileges

Users shall be assigned different Access Privileges based on external agreements between the User and the Provider.

These Access Privileges are assocated with individual Users rather than just a company, to ensure that only authorized

Users within a company have the appropriate access.

The following Access Privileges shall be available as a minimum:

a. Access Privilege Read-Only: The User may only read publicy availabe TS Information.

b. Access Privilege for Transaction: The Customer is authorized to transact Service Requests.

c. Access Privilege Read/Write: A Secondary Provider shall have write access to his own Provider Account on

an OASIS Node.

5.3 OASIS Response Time Requirements

TSIPs can only be responsible for the response capabilities of two portions of the Internet-based OASIS net work:

• The response capabilities of the OASIS Node server to process interactions with Users

• The bandwidth of the connection(s) between the OASIS Node server and the Internet.

Therefore, the OASIS response time requirements are as follows:

a. OASIS Node Server Response Time: The OASIS Node server shall be capable of supporting its connection(s)

to Users with an average aggregate data rate of at least ‘‘A’’ bits per second. ‘‘A’’ is defined as follows:

A = N * R bits/sec

where

N = 5% of registered Customers.

and

R = 28,800 bits/sec per Customer.

b. OASIS Node Network Connection Bandwidth: The bandwidth ‘‘B’’ of the OASIS Node conection(s) to the Internet

shall be at least:

B = 2 * A bits/sec

C. Time to Meet Response Requirements: The minimum time response shall be met within 1 month of User registration

for any single new User. If more than 10 new Users register in one month, 2 months lead time shall be permitted

to expand/upgrade the OASIS Node to meet the response requirements.

5.4 OASIS Provider Account Availability

The following are the OASIS Provider Account availability requirements:

a. OASIS Provider Account Availability: The availability of each OASIS Provider account on an OASIS Node shall

be at least 98.0% (downtime of about 7 days per year).

Availability is defi

Total Time

ned as:

% Availability = (1 Cumulative Provider Account Downtime) − *100

A Provider account shall be considered to be down, and downtime shall be accumlated, upon occurrence of any

of the following:
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38995

1. One or more Users cannot link and log on to the Provider account. The downtime accumulated shall be calculated

as:

3 è for affected Users of 1/n * (Login Time), which is the time used by each affected User to try to link and

log on to the Provide account, and where ‘‘n’’ is the total number of Users actively registered for the Provider account.

2. One or more Users cannot access TS Information once they have logged on to a Provider account. The downtime

accumulated shall be calculated as:

3 è for affected Users of 1/n * (Access Time), which is the time used by each affected User to try to access

data, and where ‘‘n’’ is the total number of Users actively registered for that Provider.

3. A five (5) minute penalty shall be added to the cumulative downtime for every time a User loses their connection

to a Provider’s account due to an OASIS Node momentary failure or problem.

5.5 Backup and Recovery

The following backup and recovery requirements shall be met:

a. Normal Backup of TS Information: Backup of TS Information and equipment shall be provided within the OASIS

Nodes so that no data or transaction logs are lost or become inaccessible by Users due to any single point of failure.

Backed up data shall be no older than 30 seconds. Single points of failure include the loss of one:

• Disk drive or other storage device

• Processor

• Inter-processor communications (e.g., LAN)

• Inter-OASIS communications

• Software application

• Database

• Communication ports for access by Users

• Any other single item which affects the access of TS Information by Users

b. Spurious Failure Recovery Time: After a spurious failure situation, all affected Users shall regain access to all

TS Information within 30 minutes. A spurious failure is a temporary loss of services which can be overcome by rebooting

a system or restarting a program. Permanent loss of any physical component is considered a catastrophic failure.

c. Long-Term Backup: Permanent loss of critical data due to a catastrophic failure shall be minimized through

off-line storage on a daily basis and through off-site data storage on a periodic basis.

d. Catastrophic Failure Recovery: Recovery from a catastrophic failure or loss of an OASIS Node may be provided

through the use of alternate OASIS Nodes which meet the same availability and response time requirements. TSIPs

may set up prior agreements with other TSIPs as to which Nodes will act as backups to which other Nodes, and

what procedure will be used to undertake the recovery. Recovery from a catastrophic failure shall be designed to

be achieved within 24 hours.

5.6 Time Synchronization

The following are the time requirements:

a. Time Synchronization: Time shall be synchronized on OASIS Nodes such that all time stamps will be accurate

to within ‘‘0.5 second of official time. This synchronization may be handled over the network using NTP, or may

be synchronized locally using time standard signals (e.g. WWVB, GPS equipment).

b. Network Time Protocol (NTP): OASIS Nodes shall support the Internet tool for time synchronization, Network

Time Protocol (NTP), which is described in RFC–1350, version 3, so that Users shall be able to request the display

and the downloading of current time on an OASIS Node for purposes of user applications which might be sensitive

to OASIS time.

5.7 TS Information Timing Requirements

The TS Information timing requirements are as follows, except they are waived during emergencies:

a. TS Information Availability: The most recent Provider TS information shall be available on the OASIS Node

within 5 minutes of its required posting time at least 98% of the time. The remaining 2% of the time the TS Information

shall be available within 10 minutes of its scheduled posting time.

b. Notification of Posted or Changed TS Information: Notification of TS Information posted or changed by a Provider

shall be made available within 60 seconds of the log.

c. Acknowledgment by the TSIP: Acknowledgment by the TSIP of the receipt of User Purchase requests shall occur

within 1 minute. The actual negotiations and agreements on Purchase requests do not have time constraints.

5.8 TS Information Accuracy

The following requirements relate to the accuracy of the TS information:

a. TS Information Reasonability: TS information posted and updated by the Provider shall be validated for reasonability

and consistency through the use of limit checks and other validation methods.

b. TS Information Accuracy: Although precise measures of accuracy are difficult to establish, Providers shall use

their best efforts to provide accurate information.

5.9 Performance Auditing

The following are the performance auditing requirements:

a. User Help Desk Support: TSIPs shall provide a ‘‘Help Desk’’ that is available at least during normal business

hours (local time zone) and normal work days.

b. Monitoring Performance Parameters: TSIPs shall use their best efforts to monitor performance parameters. Any

User shall be able to read or down load these performance statistics.

5.10 Migration Requirements

Whenever a new version of the S&CP is to be implemented, a migration plan will be developed for cutting over

to the new version.
38996 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

Appendix A—Data Element Dictionary

Version 1.2

May 27, 1998

Data dictionary element name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

AFFILIATElFLAG ................... AFFLAG ...... 1(ALPHANUMERIC)3 ........ Valid Values

YES

NO

Set to YES if customer is an affiliate of the provider.

ANClSERVICElTYPE .......... ANCTYPE ... 1(ALPHANUMERIC)20 ...... Valid types ............................ El—Energy Imbalance.

• EL ..................................... EP—Spinning Reserve.

• SP ..................................... SU—Supplemental Reserve.

• SU ..................................... RV—Reactive supply and Voltage Control.

• RV ..................................... RF—Regulation and Frequency

response.

• RF ..................................... SC—Scheduling, system Control

and Dispatch.

• SC ..................................... (Registered) must be registered

with www.tsin.com and listed in

the ANCSERV template.

• (Registered).

ANClSVClLINK .................... ANCSVCLINK.1(ALPHANUMERIC)300 .... Formatted string as follows.

SC:(AA); RV: (AA); RF:

(AA[:xxx[:yyy[:nnn]]]);

EL:

(AA[:xxx[:yyy[:nnn]]]);

SP:

(AA[:xxx[:yyy[:nnn]]]);

SU ........................................

(AA[:xxx[:yyy[:nnn]]]);

(Registered):

(AA[:xxx[:yyy[:nnn]]]);

The method for linking ancillary

services to a transmission

service request. The provider

and capacity of each ancillary

service is identified using the

formated string:

SC:(AA); RV:(AA);

RF:AA[:xxx[:yyy[:nnn]]]); El:

(AA[:xxx[:yyy[:nnn]]]);

SP:(AA[:xxx[:yyy[:nnn]]]):SU:

(AA|:xxx|:yyy| nn|||):

[Registered):(AA[:xxx[:yyy[:nnn]]])

where AA is the appropriate PRIMARYlPROVIDERlCODE,

SELLERlCODE; or CUSTOMERlCODE, and represents the company providing

the ancillary services. ‘‘AA’’

may be unspecified for ‘‘xxx’’

type identical to ‘‘FI’’, in which

case the ‘‘:’’ character must be

present and precede the ‘‘FT’’

type.

If multiple ‘‘AA’’ terms are necessary, then each ‘‘AA’’ grouping will be enclosed within parenthesis, with the overall

group subordinate to the

ANClSVClTYPE: specified

within parenthesis.

and where xxx represents either:

—‘‘FT’’ to indicate that the Customer will determine ancillary

services at a future time, or

—‘‘SP’’ to indicate that the Customer will self-provide the ancillary services, or
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38997

Data dictionary element name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

—‘‘RQ’’ to indicate that the Customer is asking the OASIS to

initiate the process for making

an ancillary services reservation with the indicated Provider

or Seller on behalf of the Customer. The Customer must

then continue the reservation

process with the Provider or

Seller. If the transmission services request is for

preconfirmed service, then the

ancillary services shall also be

preconfirmed, or

—‘‘AR’’ to indicate an assignment

reference number sequence

follows.

The terms ‘‘yyy’’ and ‘‘nnn’’ are

subordinate to the xxx type of

‘‘AR’’ yyy represents the ancillary services reservation number (ASSIGNMENTlREF) and

nnn represents the capacity of

the reserved ancillary services.

Square brackets are used to

indicated optional elements

and are not used in the actual

linkage itself. Specifically, the

:yyy is applicable to only the

‘‘AR’’ term and the :nnn may

optionally be left off if the capacity of ancillary services is

the same as for the transmission services, and optionally multiple ancillary reservations may be indicated by additional (xxx[:yyy[:nnn]]) enclosed

within parenthesis. If no capacity amount is indicated, the required capacity is assumed to.

ANClSVClREQ .................... ANCSVCREQ.1(ALPHANUMERIC)100 .... EI: (M.R.O.U); SP;

(M.R.O.U);.

SU: (M.R.O.U);

RV: (M.R.O.U):

RF: (M.R.O.U);

SC: (M.R.O.U):

(registered): (M.R.O.U)

Ancillary services required for a

transmission services offering.

The appropriate letter

(M.R.O.U) will be assigned to

each of the six Proforma FERC

ancillary services (see

ANClSERVICElTYPE),

where the letters mean the following:

(M) Mandatory, which implies

that the Primary Provider must

provide the ancillary service

(R) Required, which implies

that the ancillary service is required, but not necessarily

from the Primary Provider (O)

Optional, which implies that the

ancillary service is not necessarily required, but could be

provided.

(U) Unknown, which implies that

the requirements for the ancillary service are not known at

this time.

ALTERNATElSERVICElFLAG.ALTSVCFLG 2(ALPHANUMERIC)3 ........ Defaulted to ‘‘YES’’ .............. Used as a flag to identify this

reservation as a NON-FIRM

use of FIRM transmission services on an alternate point of

delivery.
38998 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

Data dictionary element name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

ASSIGNMENTlREF ............... AREF .......... 1(ALPHANUMERIC)12 ...... Unique value ........................ A unique reference number assigned by a Transmission Information Provider to provide a

unique record for each transmission or ancillary service request. A single transmission or

ancillary service request will be

over a contiguous time period,

i.e. from a STARTlTIME to

an STOPlTIME.

BIDlPRICE ............................. BIDPR ......... 1(NUMERIC)5 +‘‘.’’ .............

+2(NUMERIC)12 ................

Positive number with 2 decimals.The current bid price of a Service

in dollars and cents. Used by

Customers to designate a price

being bid.

CAPACITY ................................ CAP ............. 1(NUMERIC)12 .................. Non-negative number in

units of MW.

Transfer capability is the measure of the ability of the interconnected electric system to

readily move or transfer power

from one area to another over

all transmission lines (or paths)

between those areas under

specified system conditions. In

this context ‘‘area’’ may be an

individual electric system,

powerpool, control area, subregion, or NERC region or portion thereof.

CAPACITYlCURTAILED ........ CAPCUR ..... 1(NUMERIC)12 .................. Non-negative number in

units of MW.

The amount of transfer capability

curtailed by the Primary provider for emergency reasons.

CAPACITYlSCHEDULED ...... CAPSCH ..... 1(NUMERIC)12 .................. Non-negative number in

units of MW.

Transfer capability scheduled on

each path.

CATEGORY .............................. CAT ............. 1(ALPHANUMERIC)25 ...... Valid name from CATEGORY in LIST Template.A name to be used to categorize

messages. Valid names would

include: Discount, Want-Ad,

Curtailment, Outage, Oasis

Maint Notice.

CELINGlPRICE ...................... CEILPR ....... 1(NUMERIC)5 + ‘‘.’’ +

2(NUMERIC)2.

Positive number with 2 decimals..Ceiling price of the Service as

entered by the Transmission

Provider.

COLUMNlHEADERS ............. HEADERS ... 1(ALPHANUMERIC) Limited to all the elements

nameS in one Template.

Headers surrounded with A

and separated by commas. Limited to valid Template element names.

Must use full element

name and not alias.

Example: COLUMNlHEADER=

APATHlNAME’’,

POINTlOFlRECEIPT’’,

POINTl OFlDELIVERY’’,

‘‘SOURCE’’, ‘‘SINK’’.

CONTINUATIONlFLAG ......... CONT .......... 1(ALPHANUMERIC)1 ........ ‘‘Y’’ OR ‘‘N’’ .......................... Indicates whether or not this

record is a continuation from

the previous record.

CONTROLlAREA ................... AREA .......... 1(ALPHANUMERIC)20 ...... Valid name of a control area A part of the power system with

metered tie lines and capable

of matching generation and

load while meeting scheduled

interchange. Location of Ancillary services is my

CONROLlAREA.

CURTAILMENTlOPTIONS .... CUROPT ..... 1(ALPHANUMERIC)80 ...... Free form text ....................... Customer options, if any, to avoid

curtailment.

CURTAILMENTlPROCEDURES.CURPROC .. (ALPHANUMERIC)80 ........ Free form text ....................... Curtailment procedures to be followed in the event of a curtailment.

CURTAILMENTlREASON ..... CURREAS .. (ALPHANUMERIC)80 ........ Free form text ....................... Reason for curtailment of service.

CUSTOMERlCODE ............... CUST .......... 1(ALPHANUMERIC)6 ........ Unique value, registered on

TSIN.COM.

Any entity (or its designated

agent) that is eligible to view

OASIS information, to execute

a service agreement, and/or to

receive transmission service.

CUSTOMERlCOMMENTS ..... CUSTCOM .. 1(ALPHANUMERIC)80 ...... Free-form text ....................... Informative text.

CUSTOMERlDUNS ............... CUSTDUNS 9(NUMERIC)9 .................... Unique DUNS number ......... Unique DUNS number for a Customer.

CUSTOMERlEMAIL ............... CUSTEMAIL 1(ALPHANUMERIC)25 ...... Valid Internet E-Mail address Internet E-Mail address of Customer contract person.
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 38999

Data dictionary element name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

CUSTOMERlFAX ................... CUSTEFAX 14(ALPHANUMERIC)20 .... Area code and telephone

number, plus any extensions (aaa)-nnn-nnnn

xnnnn.

Fax phone number of Customer

contract person.

CUSTOMERlNAME ............... CUSTNAME (ALPHANUMERIC)25 ........ Free form text ....................... Name of Customer contract person.

CUSTOMERlPHONE ............. CUSTPHON 14(ALPHANUMERIC)20 .... Area code and telephone

number, plus any extensions (aaa)-nnn-nnnn

xnnnn.

Telephone of Customer contact

person.

DATAlROWS ......................... ROWS ......... 1(NUMERIC) unlimited ....... Positive Number ................... Number of records (rows) of data

exclusive of header information

that are to be uploaded or

downloaded in a file.

DATElTIMElEFFECTIVE ..... TIMEEFCT .. 16(ALPHANUMERIC)16 .... Valid date and time in seconds yyyy+mo+dd+hh

+mm+ss+tz.

Date and time a message or

service offer is in effect.

DATElTIMElPOSTED .......... TIMEPSTD .. 16(ALPHANUMERIC)16 .... Valid date and time in seconds yyyy+mo+dd+hh

+mm+ss+tz.

Date and time to seconds a message or service offered was

posted.

DEALlREF .............................. DREF .......... 1(ALPHANUMERIC)12 ...... Unique value, Assigned by

Customer.

The unique reference assigned

by a Customer to two or more

service purchases to identify

each of them as related to others in the same power service

deal. These requests may be

related to each other in time

sequence through a single Provider, or as a series of wheels

through multiple Providers, or a

combination of both time and

wheels. The User uses the

DEALlREF to uniquely identify a combination of requests

relating to a particular deal.

DISCRETIONlDESCRIPTION DISCDESC 0(ALPHANUMERIC)1000 .. Free form text ....................... A detailed description of the discretion being reported.

ELEMENTlNAME ................... ELEMENT ... 1(ALPHANUMERIC)40 ...... Valid Template element

name.

Template element name as indicated in data dictionary.

EMPLOYEElNAME ................ EMPNAME .. 1(ALPHANUMERIC)25 ...... Free form text ....................... Name of person who is transferring from one position to another.

ERRORlMESSAGE ............... ERROR ....... 1(ALPHANUMERIC)250 .... Free form text ....................... Error message related to a

RECORDlSTATUS or REQUESTlSTATUS.

FORMERlCOMPANY ............ FORMCO .... 1(ALPHANUMERIC)25 ...... Free form text ....................... Former company of the person

who is transferring.

FORMERlDEPARTMENT ...... FORMDEPT 1(ALPHANUMERIC)25 ...... Free form text ....................... Former department of the person

who is transferring.

FORMERlPOSITION ............. FORMPOS .. 1(ALPHANUMERIC)25 ...... Free form text ....................... Former position held by the person who is transferring.

INTERFACElTYPE ................ INTERFACE 1(ALPHANUMERIC)1 ........ I,E ......................................... Type of interface define by path:

Internal (I) to a control area or

External (E) to a control area.

LISTlITEM .............................. ITEM ........... 1(ALPHANUMERIC)50 ...... Free form text ....................... Item from list, such as list of

SELLERs, list of PATHs, list of

PORs, list of PODs, Lists of

SERVICElINCREMENT,

TSlCLASS, TSlTYPE,

TSlPERIOD, NERCl CURTAILMENTlPRIORITY,

OTHERlCURTAILMENTl

PRIORITY, SERVICElINCREMENT, CATEGORY List of TEMPLATEs.

LISTlITEMl DESCRIPTION ITEMDESC 0(ALPHANUMERIC)100 .... Free form text ....................... A detailed description of the

LISTlITEM.
39000 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

Data dictionary element name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

LISTlNAME ............................ LIST ............ 1(alphanumeric)25 ............. LIST, SELLER, PATH, POR,

POD, SERVICElINCREMENT,

TSlCLASS, TSlTYPE,

TSl PERIOD,

TSlSUBCLASS, ANCILLARYl SERVICEl

TYPE, CATEGORY, TEMPLATE.

List of valid names for each of

the types of lists. The minimum

set of lists defined must be implemented.

MESSAGE ................................ MSG ............ 1(ALPHANUMERIC)200 .... Free form text ....................... An informative text message.

NEGOTIATEDlPRICElFLAG NGPRIFLG .. 1(ALPHANUMERIC)1 ........ H, L, or blank ....................... Set to H if OFFERlPRICE is

higher than the currently posted price; set to L if

OFFERlPRICE is lower than

the currently posted price.

NERClCURTAINMENTl

PRIORITY.

NERCURT .. 1(NUMERIC)1 .................... Integer 1–7 ........................... One of the NERC seven curtailment priorities, documented in

LIST templat.

NEWlCOMPANY .................... NEWCO ...... 1(ALPHANUMERIC)25 ...... Free form text ....................... New company of the person who

is transferring.

NEWlDATA ............................ NEWDATA .. 1(ALPHANUMERIC)200 .... Any valid date element value For audit log, the new updated

value of a Template data element after update.

NEWlDEPARTMENT ............. NEWDEPT .. 1(ALPHANUMERIC)25 ...... Free form text ....................... New department of the person

who is transferring.

NEWlPOSITION ..................... NEWPOS .... 1(ALPHANUMERIC)25 ...... Free form text ....................... New position held by the person

who is transferring.

OFFERlPRICE ....................... OFFPR ........ 1(NUMERIC)5 + ‘‘.’’ +

2(NUMERIC)2.

Positive number with 2 decimals.The current offered price of a

Service in dollars and cents.

Used by the Seller to indicate

the offering price.

OFFERlSTARTlTIME .......... OFFSTIME .. 16(ALPHANUMERIC)16 .... Valid Date and Time to seconds:.

yyyy+mo+dd+hh+mmm+

ss+tz.

Start time of the window during

which a Customer may request

a discounted offer.

OFFERl STOPlTIME ........... OFFSPTIME 16(ALPHANUMERIC)16 .... Valid Date and Time to seconds:

yyyy+mo+dd+hh

+mm+ss+tz.

Stop time of the window during

which a Customer may request

a discounted offer. (Expiration

time of an offer).

OLDlDATA ............................. OLDDATA ... 1(ALPHANUMERIC)200 .... Any valid data element value For audit log, the old value of a

Template data element prior to

being updated. This element is

not applicable in the audit log

for transaction events.

OPTIONALlCODE .................. N/A .............. 0(ALPHANUMERIC)25 ...... Unique path name within region.OPTIONALlCODE—25 chars,

unique for Path. If used for

directionality, then the first 12

characters shall represent

POR, followed by >->, followed

by 12 characters which shall

represent POD. Used by

PATHlNAME.

OTHERlCURTAILMENT

lPRIORITY.

OTHCUR ..... 0(ALPHANUMERIC)8 ........ Free form tect ....................... Other than NERC curtailment priorities, such as regional curtailment priorities. Suggested format region+number, for example MAPP4, WSCC7. Documented in LIST template.

OUTPUTlFORMAT ................ FMT ............. 4(ALPHANUMERIC)4 ........ HTML, DATA ........................ Format of response:

HTML = hypertext markup language for presentation using a

web browser.

DATA = text for use in a

downloaded file.

PATHlCODE .......................... N/A .............. 0(ALPHANUMERIC)12 ...... Unique code for each path

as defined by primary provider.

Unique code within a Region for

each path. Used by

PATHlNAME.
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 39001

Data dictionary element name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

PATHlNAME .......................... PATH .......... 5(ALPHANUMERIC)50 ...... Unique value ........................ The unique name assigned to a

single transmission line or the

set of one or more parallel

transmission lines whose

power transfer capabilities are

strongly interrelated and must

be determined in aggregate.

These lines are typically described as being on a path,

corridor or interconnection in

some regions, or as crossing

an interface or cut-plane in

other regions. Multiple lines

may be owned by different parties and require prorating of

capability shares.

The name is constructed from

the following codes, with each

code separated by a ‘‘/’’. Trailing ‘‘/’’ may be omitted, if there

are no values for OPTIONlCODE and

SPARElCODE:.

REGIONlCODE—2 chars,

unique to OASIS System

PRIMARYlPROVIDERlCODE—

4 chars, unique within Region.

PATHlCODE—12 chars, unique

for Primary Provider.

OPTIONALlCODE—25 chars,

unique for Path. If used for

directionality, then the first 12

characters shall represent

POR, followed by >->, followed

by 12 characters which shall

represent POD

SPARElCODE—3 chars.

POINTl OFlDELIVERY ........ POD ............ 1(ALPHANUMERIC)12 ...... Unique value within Primary

Provider.

Point of Delivery is one or more

point(s) of interconnection on

the Transmission Provider’s

transmission system where capacity and/or energy transmitted by the Transmission Provider will be made available to

the Receiving Party. This is

used along with Point of Receipt to define a Path and direction of flow on that path. For

internal paths, this would be a

specific location(s) in the area.

For an external path, this may

be an area-to-area interface.

POINTlOF lRECEIPT .......... POR ............ 1(ALPHANUMERIC)12 ...... Unique value within Primary

Provider.

Point of Receipt is one or more

point(s) of interconnection on

the Transmission Provider’s

transmission system where capacity and/or energy transmitted will be made available to

the Transmission Provider by

the Delivering Party. This is

used along with Point of Delivery to define a Path and direction of flow on that path. For

internal paths, this would be a

specific location(s) in the area.

For an external path, this may

be an area-to-area interface.

POSTINGlNAME .................... POSTNAME 1(ALPHANUMERIC)25 ...... Free form text ....................... Name of person who is posting

the information on the OASIS.
39002 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

Data dictionary element name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

POSTINGlREF ....................... POSTREF ... 1(ALPHANUMERIC)12 ...... Unique Value ........................ Assigned by TSIP when Service

or Message is received by

TSIP. Unique number can be

used by the user to modify or

delete the posting.

PRECONFIRMED ..................... PRECONF .. 2(ALPHA)3 ......................... YES or NO ........................... Used by Customer to preconfirm

sale in Template transrequest

or ancrequest. If customer indicates sale is preconfirmed,

then the response is YES and

the customer does not need to

confirm the sale.

PRICElUNITS ........................ UNITS ......... 1(ALPHA)20 ....................... Free form text ....................... The units used for CEILINGlPRICE,

OFFERlPRICE, and

BIDlPRICE.

Examples: $/MWhr, $/MWmonth

PRIMARYl PROVIDERlCOMMENTS.PPROVCOM 1(ALPHANUMERIC)80 ...... Free form text ....................... Informative text. Usually entered

by the Primary Provider

through a back end system.

PRIMARYl PROVIDERlCODE.PROVIDER 1(ALPHANUMERIC)4 ........ Unique code ......................... Unique code for each Primary

Provider. used by

PATHlNAME and in URL.

Registered as part of URL at

www.tsin.com.

PRIMARYl PROVIDERlDUNS.PPROVDUNS.9(NUMERIC)9 .................... Valid DUNS number ............. Unique code for each Primary.

Provided by Dun and Bradstreet.

REASSIGNEDl CAPACITY ... RASCAP ..... 1(NUMERIC)12 .................. Positive number, cannot exceed previous assigned

capacity.

The amount of transfer capability

that was reassigned from one

entity to another.

REASSIGNEDl REF .............. REREF ........ 1(ALPHANUMERIC)12 ...... Unique value ........................ When customer makes a purchase of a transmission service that was posted for resale

and a new ASSIGNMENTlREF number is issued

the previous ASSIGNMENTlREF number now becomes the REASSIGNMENTlREF. Also used by

SELLER when posting transmission or ancillary services for

resale to show the previous assignment reference number.

Also used by the customer

when making a request to use

FIRM service as NON-FIRM

over alternate points of delivery.

REASSIGNEDlSTARTlTIME RESSTIME .. 16(ALPHANUMERIC)16 .... Valid date and time to seconds:

yyyy+mo+dd+hh+tz ..............

Beginning date and time of the

reassigned transmission service.

REASSIGNEDlSTOPlTIME RESSPIME 16(ALPHANUMERIC)16 .... Valid date and time to hour:

yyyy+mo+dd+hh+tz ..............

Date and time of the end of the

transmission service that is reassigned to another User.

RECORDlSTATUS ................ RECSTATUS.1(NUMERIC)3 .................... Error number ........................ Record status indicating record

was successful or error code if

unsuccessful.

200=Successful
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 39003

Data dictionary element name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

REGIONlCODE ...................... N/A .............. 1(ALPHANUMERIC)2 ........ Unique within OASIS System.Defined for NERC regions, with

the following defined:

E—ECAR.

I—MAIN.

S—SERC.

T—ERCOT.

A—MAPP.

P—SPP.

M—MAAC.

N—NPCC.

W—WSCC.

Second character or digit reserved for subregion id as defined by each region.

REQUESTlREF ...................... RREF .......... 1(ALPHANUMERIC)12 ...... Unique value ........................ A reference uniquely assigned by

a Customer to a request for

service from a Provider.

REQUESTlSTATUS ............... RSTATUS ... 1(NUMERIC)3 .................... Error number ........................ Message status indicating message was successful (if all

RECORDlSTATUS show

success) or error code if any

RECORDlSTATUS showed

unsuccessful.

200=Successful.

RESPONSElTIMElLIMIT ..... RESPTL ...... 16(ALPHANUMERIC)16 .... Valid date and time to seconds:

yyyy+mo+dd+hh

+mm+ss+tz ...........................

Date and time to seconds by

when a response must be received from a Customer.

RESPONSIBLElPARTYlNAME.PARTNAME 1(ALPHANUMERIC)25 ...... Free form text ....................... The name of the person responsible for granting the discretion.

RETURNlTZ ........................... TZ ................ 2(ALPHANUMERIC)2 ........ AD, AS, PD, PS, ED, ES,

MD, MS, CD, CS, UT.

A time zone code, indicating the

base time zone, and whether

daylight saving time is to be

used. This field may be set by

a Customer in a query. Returned date and time data is

converted to this time zone.

SALElREF .............................. SREF .......... 1(ALPHANUMERIC)12 ...... Unique value ........................ Identifier which is set by seller

(including Primary Provider)

when posting a service for

sale.

SELLERlCODE ...................... SELLER ...... 1(ALPHANUMERIC)6 ........ Unique value ........................ Organization name of Primary

Provider or Reseller.

SELLERlCOMMENTS ........... SELCOM ..... 1(ALPHANUMERIC)80 ...... Free form text ....................... Informative text provided by the

Seller.

SELLERlDUNS ...................... SELDUNS ... 9(NUMERIC)9 .................... Valid DUNS number ............. Unique Data Universal Numbering System provided by Dun

and Bradstreet. Code for a Primary Provider or Seller.

SELLERlEMAIL ...................... SELEMAIL .. 5(ALPHANUMERIC)60 ...... Valid network reference ....... E-Mail address of Seller contact

person.

SERVICElINCREMENT ......... SRVINCR .... 1(ALPHANUMERIC)8 ........ Valid increments

• HOURLY

• Daily

• Weekly

• Monthly

• Yearly

• {Registered}

The transmission service increments provided. Five are predefined, while additional increments can be used if they are

registered on TSIN.COM and

shown in the Provider’s LIST

template.

SELLERlFAX ......................... SELFAX ...... 14(ALPHANUMERIC)20 .... Area code and telephone

number, plus any extensions Example: (aaa)-nnnnnnn-xnnnn.

The fax telephone number for

contact person at Seller.

SELLERlNAME ...................... SELNAME ... 1(ALPHANUMERIC)25 ...... Free form text ....................... The name an individual contact

person at the Seller.

SELLERlPHONE .................... SELPHONE 14(ALPHANUMERIC)25 .... Free form text ....................... The telephone number of a contact person as a Seller.

SERVICElDESCRIPTION ...... SVCDESC ... 1(ALPHANUMERIC)200 .... Free form text ....................... Information regarding a service.

SERVICElNAME .................... SVCNAME .. 1(ALPHANUMERIC)25 ...... Free form text ....................... Name of service affected by the

discretionary action.

SERVICElTYPE ..................... SVCTYPE ... 1(ALPHANUMERIC)25 ...... Free form text ....................... Type of service affected by the

discretionary action.
39004 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

Data dictionary element name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

SINK ......................................... SINK ............ 0(ALPHANUMERIC)14 ...... Valid area name ................... The area in which the SINK is located.

SOURCE .................................. SOURCE ..... 0(ALPHANUMERIC)14 ...... Valid area name ................... The area in which the SOURCE

is located.

SPARElCODE ........................ N/A .............. 0(ALPHANUMERIC)3 ........ Defined by region ................. Spare code to be used at a later

time. Used by PATHlNAME.

STANDARDSl OFl CONDUCTlISSUE.STDISSUE .. 0(ALPHANUMERIC)200 .... Free form text ....................... Issues that were in violation of

the FERC Standards of Conduct.

STARTlTIME .......................... STIME ......... 16(ALPHANUMERIC)16 .... Valid date and time to seconds:

yyyy+mo+dd+hh

+mm+ss+tz

Start date and clock time of a

service. When used as a query

variable, it requires the return

of all items whose Stop time is

after the Start time.

Note that for some Templates

when used as a query variable

the time may be only valid up

to the hour, day or month. If

more data is given than is

valid, the hour, day or month

will be used to make the date

and time inclusive, i.e. date or

time will be truncated to valid

hour, day or month.

STARTl TIMEl POSTED ..... STIMEP ....... 16(ALPHANUMERIC)16 .... Valid Date and Time to seconds:

xlyyyy+mo+dd+hh ................

+mm+ss+tz

Query parameter to indicate all

the records are to be retrieved

that were posted on or after

this time.

STARTl TIMEl QUEUED .... STIMEQ ...... 16(ALPHANUMERIC)16 .... Valid Date and Time to seconds:

yyyy+mo+dd+hh

+mm+ss+tz

Start date and clock time of a

service, used for requesting

transactions queued after this

time.

STATUS .................................... STATUS ...... 5(ALPHANUMERIC)25 ...... Valid field (QUEUED, RECEIVED, STUDY, REBID,

OFFER, ACCEPTED, REFUSED, CONFIRMED,

WITHDRAWN, DISPLACED, ANNULLED,

RETRACTED).

QUEUED=initial status assigned

by TSIP on receipt of ‘‘customer capacity purchase request’’.

RECEIVED=reassigned by TP to

acknowledge QUEUED requests and indicate the service

request is being evaluated.

STUDY=assigned by TP to indicate some level of study is required or being performed to

evaluate service request.

OFFER=assigned by TP to indicate that an OFFERlPRICE

is being proposed.

REBID=assigned by TC to indicate a new BIDlPRICE is

being proposed.

ACCEPTED=assigned by TP to

indicate service request has

been approved/accepted. If the

reservation request was submitted PRECONFIRMED,

OASIS shall immediately set

the reservation status to CONFIRMED. Depending upon the

type of ancillary services required, the Seller may or may

not require all ancillary service

reservations to be completed

before accepting a request.

REFUSED=assigned by TP to indicate service request has

been denied, SELLERlCOMMENTS should be

used to communicate reason

for denial of service.
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 39005

Data dictionary element name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

CONFIRMED=assigned by TC in

response to TP posting ‘‘ACCEPTED’’ status to confirm

service.

WITHDRAWN=assigned by TC at

any point in request evaluation

to withdraw the request from

any further action.

DISPLACED=assigned by TP

when a ‘‘CONFIRMED’’ request from a TC is displayed

by a longer term request and

the TC has exercised right of

first refusal (i.e. refused to

match T&Cs of new request).

ANNULLED=assigned by TP

when, by mutual agreement

with the TC, the transaction is

to be voided.

RETRACTED=assigned by TP

when the TC fails to confirm or

withdraw the transaction within

the required time period.

STATUSlCOMMENTS ........... STACOM ..... 1(ALPHANUMERIC)80 ...... Free form text ....................... Informative text.

STATUSlNOTIFICATION ....... STATNOT ... 1(ALPHANUMERIC)200 .... http://URL:portnumber/directr

y/cgi script/query parameters or Mailto: <e-mail

address.>.

The STATUSlNOTIFICATION

data element shall contain the

rptocol field ‘‘http:’’, which designates the notification method/

protocol to be used, followed

by all resource location information required; the target domain name and port designations shall be inserted into the

notification URL based on the

Customer’s company registration information. The resource

location information may include directory information, cgi

script identifiers and URL encoded query string name/value

pairs as required by the Customer’s application, or mailto

and email address for the status information the Customer

wants to receive upon a

change in STATUS of

transstatus, or ancstatus.

STOPlTIME ............................ SPTIME ....... 16(ALPHANUMERIC)16 .... Valid date and time yyyy +

mo + ddd + hh + mm +

ss+tz.

Stop date and clock time. When

used as a query variable, it requires the return of all items

which start before the stop

time.

Note that for some Templates

when used as a query variable

the time may be only valid up

to the hour, day or month. If

more data is given than is

valid, the hour, day or month

will be used to make the date

and time inclusive, i.e. date or

time will be increased to include STOPlTIME.

STOPlTIMElPOSTED ......... STPTIMEP .. 16(ALPHANUMERIC)16 .... Valid Date and Time to seconds:

yyyy+mo+dd+hh+mm+

ss+tz.

Query parameter to indicate all

the records are to be retrieved

that were posted on or before

this time.

STOPlTIMElQUEUED ......... SPTIMEQ .... 16(ALPHANUMERIC)16 .... Valid Date and Time to seconds:

yyyy+mo+dd+hh+mm+

ss+tz.

Stop date and clock time, used

for requesting transactions

queued before this time.
39006 Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations

Data dictionary element name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

SUBJECT ................................. SUBJ ........... 1(ALPHANUMERIC)80 ...... Free form text ....................... Informative text used to summarize a topic in a message.

TARIFFlREFERENCE ........... TARIFF ....... 1(ALPHANUMERIC)150 .... Free form text. Name and

description of Tariff.

Tariffs approved by FERC.

TEMPLATE ............................... TEMPL ........ 1(ALPHANUMERIC)20 ...... Valid Name of Template

from Section 4.3 or from

LIST Template.

The name of a logical collection

of DATAlELEMENTS in a

User’s interaction with an

OASIS Node.

TIMElOFlLASTlUPDATE .. TLUPDATE 16(ALPHANUMERIC)16 .... Valid Date and Time to seconds:

yyyy+mo+dd+hh+mm+

ss+tz.

Date and time to seconds that

data was last updated. May be

used to search data updated

since a specific point in time.

TIMElPOSTED ....................... TIMEPST .... 16(ALPHANUMERIC)16 .... Valid Date and Time to seconds:

yyyy+mo+dd+hh+mm+

ss+tz.

Date and time a message is

posted.

TIMElQUEUED ...................... TIMEQ ......... 16(ALPHANUMERIC)16 .... Valid Date and Time to seconds:

yyyy+mo+dd+hh+mm+

ss+tz.

Date and time that the request

was queued.

TIMElSTAMP ......................... TSTAMP ..... 16(ALPHANUMERIC)16 .... Valid Date and Time to seconds:

yyyy+mo+dd+hh+mm+

ss+tz.

Time data is created.

TSlCLASS .............................. TSCLASS .... 1(ALPHANUMERIC)20 ...... Valid classes: .......................

• FIRM

• NON-FIRM

• TTC

• (Registered)

The transmission service classes

provided. Three are pre-defined, while additional classes

can be used if they are registered on TSIN.COM and

shown in the Provider’s LIST

template page.

TSlPERIOD ............................ TSPER ........ 1(ALPHANUMERIC)20 ...... Valid periods: .......................

ONlPEAK

OFFlPEAK

FULLlPERIOD

(Registered)

The transmission service periods

provided. Three are pre-defined, while additional periods

can be used if they are registered on TSIN.COM and

shown in the Provider’s LIST

template.
Federal Register / Vol. 63, No. 138 / Monday, July 20, 1998 /Rules and Regulations 39007

Data dictionary element name Alias

Field format: minimum

characters (type of ASCII)

maximum characters

Restricted values Definition of data element

TSlSUBCLASS ...................... TSSUBC ..... 1(ALPHANUMERIC)20 ...... Free form .............................. The transmission service subclasses provided. These are

freeform.

TSlTYPE ................................ TSTYPE ...... 1(ALPHANUMERIC)20 ...... Valid periods: .......................

• POINTlTOlPOINT

• NETWORK

• (Registered)

The transmission service types

provided. Two are pre-defined,

while additional types can be

used if they are registered on

TSIN.COM and shown in the

Provider’s LIST template.

TSlWINDOW .......................... TSWIND ...... 1(ALPHANUMERIC)20 ...... Valid periods: .......................

• FIXED

• SLIDING

• (Registered)

The transmission service windows provided. Two are predefined, while additional windows can be used if they are

registered on TSIN.COM and

shown in the Provider’s LIST

template.

TZ ............................................. TZ ................ 2(ALPHANUMERIC)2 ........ Valid time zone and indication whether daylight savings time is to be used.Time zones:

Atlantic time=AD, AS.

Eastern time=ED, ES.

Central time=CD, CS.

Mountain time=MD, MS.

Pacific time=PD, PS.

Universal time=UT.

VALIDlFROMlTIME ............. VALFTIME .. 16(ALPHANUMERIC)16 .... Valid Date and Time

yyyy+mo+dd+hh+mm+

ss+tz.

Date and time after which the

message is valid.

VALIDlTOlTIME ................... VALTTIME .. 16(ALPHANUMERIC)16 .... Valid date and time

yyyy+mo+dd+hh+mm+

ss+tz.

Date and time before which the

message is valid.

VERSION .................................. VER ............. 1(REAL NUMBER)6 ........... RANGE OF 1.0 TO 9999.9 .. Specifics which version of the

OASIS Standards and Communication Protocol to use when

interpreting the request.

[FR Doc. 98–17210 Filed 7–17–98; 8:45 am]

BILLING CODE 6717–01–M