Federal Register, Volume 63 Issue 138 (Monday, July 20, 1998)

[Federal Register Volume 63, Number 138 (Monday, July 20, 1998)]
[Rules and Regulations]
[Pages 38884-39007]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 98-17210]

[[Page 38883]]

_______________________________________________________________________

Part II

Department of Energy

_______________________________________________________________________

Federal Energy Regulatory Commission

_______________________________________________________________________

18 CFR Part 37

Open Access Same-Time Information System and Standards of Conduct;
Final Rule

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

[[Page 38884]]

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 Sec. 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 [email protected].
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 [email protected].
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 Hebert, 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).¹ The

[[Page 38885]]

current Phase I OASIS is an Internet-based electronic communication and
reservation system through which transmission providers ²
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.³ 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) ⁴ to develop suitable
OASIS standards and communications protocols.⁵ 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.⁶
---------------------------------------------------------------------------

\1\ Open Access Same-Time Information System and Standards of
Conduct, Order No. 889, FERC Stats. & Regs. para. 31,035, 61 FR
21,737 (1996); order granting request for clarification, 77 FERC
para. 61,335 (1996); order on reh'g, Order No. 889-A, FERC Stats. &
Regs. para. 31,049, 62 FR 12484 (1997); and order denying reh'g,
Order No. 889-B, 81 FERC para. 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. para. 31,036, 61 FR
21540 (1996); order on reh'g, Order No. 888-A, FERC Stats. & Regs.
para. 31,048, 62 FR 12274, 62 FR 64688 (1997); order on reh'g, Order
No. 888-B, 81 FERC para. 61,248 (1997); and order on reh'g, Order
No. 888-C, 82 FERC para. 61,046 (1998).
\2\ The term ``Transmission Provider'' is defined at
Sec. 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.''
\3\ Early 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.
\4\ A list of the abbreviations of names used in this order is
provided in Attachment 1.
\5\ Section 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.
---------------------------------------------------------------------------

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,⁷ 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.⁸ 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.
---------------------------------------------------------------------------

\7\ The minor revisions involved corrections of examples,
typographical errors, out-of-date cross references, and similar
changes.
\8\ Consistent 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 Sec. 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 Sec. 4.3.2), the status of transmission service
requests (at Sec. 4.3.7), and the status of ancillary service
requests (at Sec. 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. para. 31,049 at 30,568.
---------------------------------------------------------------------------

On June 27, 1997, the How Group proposed interim measures to allow
on-line 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 ⁹ 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 Sec. 37.6(e) temporarily mask the
identities of the parties to the transaction during and after
negotiations for transmission service.¹⁰ 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.
---------------------------------------------------------------------------

\9\ As 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.
\10\ The relevant and now deleted OASIS regulations, at
Secs. 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 Sec. 37.6(e)(1)(iii)) and must
state the reason why the transaction could not be continued or
completed. ''
---------------------------------------------------------------------------

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 on-line 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\ Comments 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.
---------------------------------------------------------------------------

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.¹² 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.
---------------------------------------------------------------------------

\12\ The 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.
---------------------------------------------------------------------------

On August 29, 1997, we issued a notice inviting public comment on
the August 12 submittal. Four comments

[[Page 38886]]

were filed and are referred to herein as ``Comments on Phase
IA''.¹³
---------------------------------------------------------------------------

\13\ Comments 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.
---------------------------------------------------------------------------

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-by-issue 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.
---------------------------------------------------------------------------

\14\ Source 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 para. 61,015 (1998), reh'g pending
(CAPT). CAPT is further discussed infra at notes 47, 74, and 76.
---------------------------------------------------------------------------

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 Sec. 37.6(e)(1)(iii) and Sec. 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\
---------------------------------------------------------------------------

\15\ See also ``service request'' transaction templates at
Sec. 4.3.5 of the S&CP Document.
\16\ Order 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.
\18\ Order No. 889-B, 81 FERC at 62,175.
---------------------------------------------------------------------------

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 Sec. 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\
---------------------------------------------------------------------------

\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.
\20\ The 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.
---------------------------------------------------------------------------

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

[[Page 38887]]

to sell their generation output with the needs of power purchasers to
meet their loads.²¹ They posit that once the location of the
generating facility (source) and the location of the load ultimately
served (sink) for each point-to-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.
---------------------------------------------------------------------------

\21\ EPSA 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.
---------------------------------------------------------------------------

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\ Florida Power Corp Comments on How Group's June 27 letter
at pp. 1-2.
---------------------------------------------------------------------------

APPA points to the technical burden that masking efforts place on
transmission providers.²³ 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.²⁴
---------------------------------------------------------------------------

\23\ APPA Comments on How Group's June 27 letter at p. 1.
\24\ APPA Comments on How Group's June 27 letter at p. 3.
---------------------------------------------------------------------------

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.²⁵ NYSEG shares the view that electricity markets may
become more efficient with more transmission information made available
on a non-discriminatory basis.²⁶
---------------------------------------------------------------------------

\25\ PJM Comments on How Group's June 27 letter at p. 1.
\26\ NYSEG Comments on How Group's June 27 letter at p. 2.
---------------------------------------------------------------------------

Southern suggests that the Commission should not unmask source and
sink information unless it has a strong policy reason to do
so.²⁷ 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.²⁸ 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.²⁹ EPSA foresees the
competitiveness of electricity markets being undermined by unmasking,
with markets eventually returning to monopoly power suppliers and
captive power purchasers.³⁰ CPEX also sees unmasking as a
serious threat to competitive electricity markets.³¹
---------------------------------------------------------------------------

\27\ Southern Comments on How Group's June 27 letter at p. 4.
\28\ EPSA 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.
\29\ EPSA 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.
\30\ EPSA Comments on How Group's June 27 letter at p. 4.
\31\ CPEX Comments on How Group's June 27 letter at pp. 3-4.
---------------------------------------------------------------------------

CCEM makes the commercial business argument that unmasking will
compel power marketers to give up the benefits that they provide
without being compensated.³² 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.
---------------------------------------------------------------------------

\32\ CCEM Comments on How Group's June 27 letter at p. 4.
---------------------------------------------------------------------------

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.³³ 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.³⁴ 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.³⁵
---------------------------------------------------------------------------

\33\ NYSEG Comments on How Group's June 27 letter at p. 1.
\34\ NRECA Comments on How Group's June 27 letter at pp. 1-2.
\35\ Commonwealth Edison Comments on How Group's June 27 letter
at p. 2.
---------------------------------------------------------------------------

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.³⁶ NRECA contends that source and sink
information will be available from the NERC transaction information
system or the tagging form.³⁷ PECO Energy and Commonwealth
Edison believe that unmasking should not be viewed as a reliability
matter.³⁸
---------------------------------------------------------------------------

\36\ Commonwealth 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.
\37\ NRECA Comments on How Group's June 27 letter at pp. 1-2.
\38\ PECO 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.
---------------------------------------------------------------------------

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.³⁹ 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,

[[Page 38888]]

complains that NERC has a policy of treating tagging information as
confidential.⁴⁰ 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.⁴¹
---------------------------------------------------------------------------

\39\ CPEX Comments on How Group's June 27 letter at pp. 1-3.
\40\ APPA Comments on How Group's June 27 letter at p. 4.
\41\ EPSA Comments on How Group's June 27 letter at pp. 5-6.
---------------------------------------------------------------------------

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 flow-based transmission
capacity pricing regime,⁴² PJM sees unmasking making no
difference.⁴³ 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.⁴⁴ 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.⁴⁵
---------------------------------------------------------------------------

\42\ Flow-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.''
\43\ PJM Comments on How Group's June 27 letter at pp. 1-2.
\44\ Florida Power Corp Comments on How Group's June 27 letter
at pp. 3-4.
\45\ APPA Comments on How Group's June 27 letter at p. 5.
---------------------------------------------------------------------------

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-to-point 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 Commission, elsewhere, has previously addressed NERC's
tagging requirements. See, CAPT supra note 15.
---------------------------------------------------------------------------

The issue here is whether to unmask, that is, make known to all
parties, point-to-point transmission service source and sink
information now made known to transmission system operators. We are
persuaded that such source and sink information ⁴⁷ 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.
---------------------------------------------------------------------------

\47\ We earlier defined the source and sink information here at
issue, supra notes 9 and 14.
---------------------------------------------------------------------------

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 after-the-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\ Our 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.]''
---------------------------------------------------------------------------

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.⁴⁹ 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.
---------------------------------------------------------------------------

\49\ We are revising the operative statement in Sec. 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.''
---------------------------------------------------------------------------

Our decision to unmask source and sink information is consistent
with

[[Page 38889]]

sections 17.2 and 18.2 of the Pro Forma Tariff.⁵⁰ 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.
---------------------------------------------------------------------------

\50\ Section 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.''
---------------------------------------------------------------------------

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.⁵¹ 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.
---------------------------------------------------------------------------

\51\ We 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.
---------------------------------------------------------------------------

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 on-line 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.⁵² 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.⁵³ 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).⁵⁴
---------------------------------------------------------------------------

\52\ CCEM Comments on Interim Measures at pp. 11-12.
\53\ CCEM Comments on Interim Measures at p. 11.
\54\ Id.
---------------------------------------------------------------------------

Commonwealth Edison argues that transmission service negotiations
off-OASIS 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\ Commonwealth Edison Comments on Interim Measures at pp. 4-
5.
---------------------------------------------------------------------------

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 real-time 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\ Southern Comments on Interim Measures at p. 2.
---------------------------------------------------------------------------

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\ Florida Power Corp Comments on Interim Measures at pp. 4-5.

---------------------------------------------------------------------------

[[Page 38890]]

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\ NRECA 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.
---------------------------------------------------------------------------

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.⁵⁹ However, it believes that price discounts should
be disclosed when offered to affiliates and non-affiliates alike,
following the completion of the negotiations.
---------------------------------------------------------------------------

\59\ PECO Energy Comments on Interim Measures at p. 7.
---------------------------------------------------------------------------

Commission Conclusion

As we stated in Order No. 889-A,⁶⁰ 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.⁶¹ Under this limited interim procedure, wherein we
merely allow the price field to be modified,⁶² 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.
---------------------------------------------------------------------------

\60\ Order No. 889-A, FERC Stats. & Regs. at 30,551.
\61\ We 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.
\62\ This modification is more fully explained in note 63,
infra.
---------------------------------------------------------------------------

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.⁶³ 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.''
---------------------------------------------------------------------------

\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 Sec. 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 Sec. 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.
---------------------------------------------------------------------------

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 on-line 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.⁶⁴ 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.⁶⁵ Additionally, interested persons
filed comments on certain of the proposed revisions to the S&CP
Document, which we also address below.
---------------------------------------------------------------------------

\64\ Changes 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.
---------------------------------------------------------------------------

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 OFFER__PRICE equal to BID__PRICE in the
case of

[[Page 38891]]

``preconfirmed'' transmission reservation requests. AEP states that
this proposal should satisfy the restriction/requirement that
BID__PRICE be equal to OFFER__PRICE for any reservation to be
CONFIRMED; ⁶⁶ 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:
---------------------------------------------------------------------------

\66\ AEP Comments on Phase IA at p. 5.
---------------------------------------------------------------------------

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 OFFER__PRICE equal to the value of
the BID__PRICE 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 OFFER__PRICE equal to the BID__PRICE 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\ See Order No. 889-A, FERC Stats. & Regs. at 30,568.
---------------------------------------------------------------------------

2. Comments on Linking Ancillary and Transmission Services
The How Group proposes adding Sec. 4.2.12 to conform the S&CP
Document to the revisions directed by Order No. 889-A in connection
with Secs. 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 pre-arranged 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\ AEP Comments on Phase IA at pp. 5-7.
---------------------------------------------------------------------------

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\ Southern Comments on Phase IA at pp. 4-5.
---------------------------------------------------------------------------

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 point-to-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 Sec. 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\ Southern Comments on Phase IA at pp. 5-6.
---------------------------------------------------------------------------

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\ AEP Comments on Phase IA at pp. 7-8.
---------------------------------------------------------------------------

Commission Conclusion

The How Group's Phase IA proposal for implementing capacity
profiles in Sec. 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

[[Page 38892]]

periods within a single request, are at the discretion of the
Primary Provider.⁷²
---------------------------------------------------------------------------

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

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.⁷³ 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.
---------------------------------------------------------------------------

\73\ PECO Comments on Phase IA at p. 2.
---------------------------------------------------------------------------

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 (NERC__CURTAILMENT__PRIORITY and OTHER__CURTAILMENT__PRIORITY)
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.⁷⁴ 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.⁷⁵
---------------------------------------------------------------------------

\74\ While 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.
\75\ How Group/Commercial Practices Group Comments on Phase IA
at pp. 1-2.
---------------------------------------------------------------------------

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.⁷⁶ We also adopt the proposed
corrective suggestions for Phase IA purposes because they improve and
help complete the S&CP Document.
---------------------------------------------------------------------------

\76\ As 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.
---------------------------------------------------------------------------

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
POINT__OF__RECEIPT and POINT__OF__DELIVERY) 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 PATH__NAME) represents the
interconnection between two NERC Control Areas, the PATH__NAME shall
be composed of: ``REGION__CODE/PRIMARY__PROVIDER__CODE/PATH__CODE//
''. REGION__CODE and PRIMARY__PROVIDER__CODE are as defined in the
Data Element Dictionary. PATH--CODE shall be composed of the
POINT__OF__RECEIPT followed by the hyphen (-) character and
POINT__OF__DELIVERY, where POINT__OF__RECEIPT and
POINT__OF__DELIVERY are the associated NERC 4 character Control Area
acronyms. OPTIONAL__CODE and SPARE__CODE are null.⁷⁷
---------------------------------------------------------------------------

\77\ AEP Comments on Phase IA at p. 2.
---------------------------------------------------------------------------

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.⁷⁸ 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.
---------------------------------------------------------------------------

\78\ AEP Comments on Phase IA at pp. 2-3.
---------------------------------------------------------------------------

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

[[Page 38893]]

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 Sec. 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.⁷⁹ 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.⁸⁰
---------------------------------------------------------------------------

\79\ 18 CFR 37.6(b)(1)(i).
\80\ Such 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).
---------------------------------------------------------------------------

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.⁸¹ 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.⁸²
---------------------------------------------------------------------------

\81\ See supra note 64.
\82\ How Group's August 12, 1997, letter at Attachment 1.
---------------------------------------------------------------------------

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\ Order 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.
---------------------------------------------------------------------------

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\ AEP 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.''
---------------------------------------------------------------------------

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 Sec. 4.2.8.2--Company Information and
Sec. 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.
---------------------------------------------------------------------------

\85\ We note that AEP's proposed procedure parallels the
registration procedure proposed by the How Group for Phase IA
dynamic notification of transmission customers.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

\86\ PECO notes that the Commission has approved at least one
tariff (Wisconsin Electric Power Company, 80 FERC para. 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.
\87\ PECO Comments on Phase IA at p. 3.
---------------------------------------------------------------------------

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

[[Page 38894]]

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.
---------------------------------------------------------------------------

\88\ See Order No. 888-A, FERC Stats. & Regs. para. 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.
---------------------------------------------------------------------------

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.
---------------------------------------------------------------------------

\89\ Order No. 889-A, FERC Stats. & Regs. at 30,574.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

\90\ The ``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.
\91\ How Group Phase II Report at p. 16.
---------------------------------------------------------------------------

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.⁹² 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.⁹³ 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.
---------------------------------------------------------------------------

\92\ Southern Comments on Phase IA at pp. 1-6.
\93\ Southern Comments on Phase IA at p. 2.
---------------------------------------------------------------------------

Commission Conclusion

As noted, Southern repeats its contention that interim measures for
on-line 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 para. 61,332 at
62,512 (1997), order on reh'g and clarification, 82 FERC para. 61,131
at 61,470-71 (1998), the Commission required transmission providers to
post organizational charts and job descriptions on their OASIS

[[Page 38895]]

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 Sec. 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.⁹⁴ The Commission will
submit the rule to both houses of Congress and the Comptroller General
prior to its publication in the Federal Register.
---------------------------------------------------------------------------

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

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
Sec. 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 Hebert 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\

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

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.

[[Page 38896]]

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.

[[Page 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)

[[Page 38898]]

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 (CCEM)
Electric Market.
Commercial Practices Working (Commercial Practices Group)
Group.
Commonwealth Edison Company...... (Commonwealth Edison)
Continental Power Exchange....... (CPEX)
Electric Clearinghouse, Inc...... (Electric Clearinghouse)

[[Page 38899]]

Electric Power Research Institute (EPRI)
Electric Power Suppliers (EPSA)
Association.
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 (NRECA)
Cooperative Association.
New York Power Pool.............. (NYPP)
New York State Electric & Gas (NYSEG)
Corp.
North American Electric (NERC)
Reliability Council.
Pennsylvania--New Jersey-- (PJM)
Maryland Power Pool.
PECO Energy Company--Power Team.. (PECO)
PECO Energy Company--Power Team (PECO Energy)
and Vitol Gas & Electric, Ltd.
Savannah Electric and Power (Savannah)
Company.
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

[[Page 38900]]

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 dial-up 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 PRIMARY__PROVIDER__CODE.
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,

[[Page 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 fetch__http) 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 off-line 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

[[Page 38902]]

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/(PRIMARY__PROVIDER__CODE)

Where:

(OASIS Node name) is the World Wide Web URL address of the OASIS
Information Provider.
(PRIMARY__PROVIDER__CODE is the 4 character acronym of the primary
provider.
(PRIMARY__PROVIDER__CODEs 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/(PRIMARY__PROVIDER__CODE)/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).

[[Page 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/(PRIMARY__PROVIDER__CODE/ (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
PATH__NAME, 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.

[[Page 38904]]

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-www-
form-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.,
``fetch__http'') 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 OUTPUT__FORMAT Query Variable:
a. HTML: If the User requests the response to have the format of
``HTML'' (OUTPUT__FORMAT=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
(OUTPUT__FORMAT=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.

[[Page 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 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'' (OUTPUT__FORMAT=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
(OUTPUT__FORMAT=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
OUTPUT__FORMAT
PRIMARY__PROVIDER__CODE
PRIMARY__PROVIDER__DUNS
RETURN__TZ
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:

[[Page 38906]]

the number 1, (e.g., PATH__NAME1=abc&PATH__NAME2=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 ``...SELLER__CODE=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,''... SELLER__CODE=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., TIME__OF__LAST__UPDATE), OASIS shall
return to the User all requested information whose associated data
element time value (e.g. TIME__OF__LAST__UPDATE) 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. START__TIME__QUEUED and
STOP__TIME__QUEUED) that represents the start and stop of a time
interval but is associated with one single template data element (e.g.
TIME__QUEUED 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. START__TIME and STOP__TIME query
variables) that represents the start and stop of one time interval but
is associated with another pair of template data elements (e.g.
START__TIME and STOP__TIME 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
START__TIME query variable selects all information whose STOP__TIME
data element value is later than the START__TIME query variable, and
the STOP__TIME query variable selects all information whose START__TIME
data element value is earlier than the STOP__TIME query variable. For
example:

The transoffering template query string ``START__TIME
970101000000ES&STOP__TIME970201000000ES'' 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.nq
TEMPLATE=aaaaaaaaaaq
OUTPUT__FORMAT=[DATA]q
PRIMARY__PROVIDER__CODE=aaaaq
PRIMARY__PROVIDER__DUNS=nnnnnnnnnq
RETURN__TZ=aaq

[[Page 38907]]

DATA__ROWS=nnnq
COLUMN__HEADERS=[Template data element names separated by commas]q

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 DATA__ROWS Data Elements shall define
the total Number of data records that follow in the message after the
COLUMN__HEADERS record.
The COLUMN__HEADERS 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 OUTPUT__FORMAT=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:

REQUEST__STATUS=nnnq
ERROR__MESSAGE=aaa...q
TIME__STAMP=yyyymmddhhmmsstzq
VERSION=nn.nq
TEMPLATE=aaaaaaaaaaq
OUTPUT__FORMAT=DATEq
PRIMARY__PROVIDER__CODE=aaaaq
PRIMARY__PROVIDER__DUNS=nnnnnnnnnq
RETURN__TZ=tzq
DATA__ROWS=nnnq
COLUMN__HEADERS=[Template data element names separated by commas]q

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 DATA__ROWS Data Element shall define
the total number of data records returned in the message following the
COLUMN__HEADERS header record.
The COLUMN__HEADERS 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 COLUMN__HEADERS 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
PRIMARY__PROVIDER__CODE 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
PRIMARY__PROVIDER__CODE 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
COLUM__HEADERS record. The number of Data Records in the message is
defined by the DATA__ROWS 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
CONTINUATION__FLAG. 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 CONTINUATION__FLAG 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 COLUMN__HEADERS other than those explicitly allowed for a particular
Template shall be ignored. However commas must be included to properly
align the fields.

[[Page 38908]]

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 RECORD__STATUS and
ERROR__MESSAGE Data Elements which are included in each data record
(row) of the Response.
If no error was encountered in an Input data record, the
RECORD__STATUS Data Element in the corresponding Response record shall
be returned with a value of 200 (success), and the ERROR__MESSAGE shall
be blank.
If any error is detected in processing an Input data
record, it shall be indicated by a RECORD__STATUS Data Element value
other than 200. The ERROR__MESSAGE 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 REQUEST__STATUS and
ERROR__MESSAGE header records (see section 4.2.7.3):
If no errors were encountered in processing the User's
Input data records, the REQUEST__STATUS shall be returned with the
value of 200 (success), and the ERROR__MESSAGE shall be blank.
If any errors were detected in the Template Input data
records, the REQUESTS__STATUS value shall be any value other than 200,
and the ERROR__MESSAGE 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 RECORD__STATUS and ERROR__MESSAGE. 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

[[Page 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 RETURN__TZ header Query Variable or an
appropriate OASIS specific default. OASIS shall interpret RETURN__TZ 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
RETURN__TZ=ES would return all time Data Elements in Eastern Standard
Time year-round. However, a RETURN__TZ=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 BID__PRICE which is different
from the OFFER__PRICE 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 STATUS__NOTIFICATION 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 OFFER__PRICE equal to the
value of BID__PRICE 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 NEGOTIATED__PRICE__ZFLAG data element
is set when the Seller agrees to a BID__PRICE (by setting OFFER__PRICE
equal to BID__PRICE that is different from the previously posted price.
It will show ``higher'' when OFFER__PRICE is higher than the posted
price, and ``lower''when the OFFER__PRICE 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
OFFER__PRICE which is different from the BID__PRICE 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 BID__PRICE 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
OFFER__PRICE 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 OFFER__PRICE less than the
posted in the transoffering (ancoffering) Template, the transoffering
(ancoffering) Template must be updated to reflect the new OFFER__PRICE.
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.

[[Page 38910]]

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 OFFER__PRICE matches BID__PRICE (i.e., seller must
set OFFER__PRICE equal to BID__PRICE prior to or coincident with
setting STATUS to accepted)
j. OASIS shall accept a customer initiated change in STATUS to
CONFIRMED only when BID__PRICE matches OFFER__PRICE (i.e. customer must
set BID__PRICE equal to OFFER__PRICE 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 OFFER__PRICE is being
proposed
REBID=assigned by TC to indicate that a new BID__PRICE is being
proposed
ACCEPTED=assigned by TP to indicate service request at the designed
OFFER__PRICE 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,
SELLER__COMMENTS 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

[[Page 38911]]

[GRAPHIC] [TIFF OMITTED] TR20JY98.001

BILLING CODE 6716-01-C

[[Page 38912]]

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 STATUS__NOTIFICATION 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 STATUS__NOTIFICATION 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 STATUS__NOTIFICATION 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 STATUS__NOTIFICATION data
element with the value of ``http:/cgi-bin/status?
DEAL__REF=8&REQUEST__REF=173'', OASIS shall deliver and HTTP
notification message using the URL: http://oasistic.xyz.com:80/cgi-bin/
status? DEAL__REF=8&REQUEST__REF=173
If the STATUS__NOTIFICATION 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 STATUS__NOTIFICATION 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 RETURN__TZ 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 ASSIGNMENT__REF of 245 would be,

GET http://oasistc.xyz.com:80chi-bin/status?
DEAL__REF=8&REQUEST__REF=173 HTTP/1.0

Content-type: text/x-oasis-csv
Content-length:
REQUEST__STATUS=200
TIME__STAMP=
VERSION=1.2
TEMPLATE=transstatus
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=ABC
PRIMARY__PROVIDER__DUNS=123456789
RETURN__TZ=
DATA__ROWS=1
COLUMN__HEADERS=CONTINUATION__FLAG, ASSIGNMENT__REF, . . .
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 STATUS__NOTIFICATION data
element. Mailto: URL's consist of the ``mailto:'' protocol identifier
and an Internet mail

[[Page 38913]]

address to which the notification message should be sent. The
STATUS__NOTIFICATION 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 STATUS__NOTIFICATION 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 ASSIGNMENT__REF
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 RETURN__TZ in formulating the transstatus response
information.
4.2.11 Reference Identifiers
The TSIP shall assign a unique reference identifier,
ASSIGNMENT__REF, for each Customer request to purchase capacity or
services. The value of ASSIGNMENT__REF 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
ASSIGNMENT__REF number is assigned, but previous ASSIGNMENT__REF
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. POSTING__REF,
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 POSTING__REF 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 ASSIGNMENT__REF
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 REASSIGNED__REF, REASSIGNED__START__TIME,
REASSIGNED__STOP__TIME, and REASSIGNED__CAPACITY data elements.
Sellers may identify their service offerings received from
Customers through the Seller supplied value specified for the SALE__REF
data element.
Customers may track their purchase requests through the Customer
supplied values specified for the DEAL__REF and REQUEST__REF data
elements. Customers may also use POSTING__REF and SALE__REF 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 ANC__SVC__REQ
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
ANC__SVC__LINK 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 PRIMARY__PROVIDER__CODE, SELLER__CODE, or
CUSTOMER__CODE, 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 ANC__SVC__TYPE 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

[[Page 38914]]

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
(ASSIGNMENT__REF) 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.

[[Page 38915]]

----------------------------------------------------------------------------------------------------------------
Process area Process name Template(s)
----------------------------------------------------------------------------------------------------------------
4.3.2 Query/Response of Posted Services Query/Response Transmission transoffering
Being Offered. Capacity Offerings.
Query/Response Ancillary Service ancoffering
Offerings.
4.3.3 Query/Response of Services Query/Response Transmission transserv
Information. Services.
Query/Response Ancillary Services ancser
4.3.4 Query/Response of Schedules and Query/Response Transmission schedule
Curtailments. Schedules.
Query/Response Curtailments...... curtail
4.3.5 Query/Response of Lists of Query/Response List of Sellers, list
Information. Paths, PORs, PODs, Capacity
Types, Ancillary Service Types,
Templates.
4.3.6 Query/Response of Audit Log....... Query/Response Audit Log......... auditlog
4.3.7 Purchase Transmission Services.... Request Purchase of Transmission transrequest
Services (Input).
Query/Response Status of transstatus
Transmission Service Request.
Seller Approves Purchase (Input). transsell
Customer Confirm/Withdraw transcust
Purchase of Transmission Service
(Input).
Alternate POD/POR................ transalt
Seller Reassign Rights (Input)... transassign
4.3.8 Seller Posting of Transmission Seller Post Transmission Service transpost
Service. for Sale (Input).
Seller Modify (Remove) transupdate
Transmission Service for Sale
(Input).
4.3.9 Purchase of Ancillary Service..... Request Purchase of Ancillary ancrequest
Service (Input).
Query/Response Status of ancstatus
Ancillary Service Request.
Seller Approves Purchase of ancsell
Ancillary Service (Input).
Customer Accept/Withdraw Purchase anccust
of Ancillary Service (Input).
4.3.10 Seller Post Ancillary Service.... Seller Post Ancillary Service ancpost
(Input).
Seller Modify (Remove) Ancillary ancupdate
Service for Sale (Input).
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. START__TIME and STOP__TIME is the requested time interval
for the Response to show all offerings which intersect that interval
(see Section 4.2.6.6). TIME__OF__LAST__UPDATE 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, OFFER__START__TIME and OFFER__STOP__TIME indicate
the ``request time window'' within which a customer must request a
service in order to get the posted OFFER__PRICE. START__TIME and
STOP__TIME indicate the time frame that the service is being offered
for.
The SERVICE__DESCRIPTION data element shall define any attributes
and/or special terms and conditions applicable to the offering that are
not listed under the standard SERVICE__DESCRIPTION associated with the
product definition supplied in the transserv or ancserv templates.
SERVICE__DESCRIPTION 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 POSTING__REF 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 SERVICE__INCREMENT data
element, namely, hourly, daily, weekly, monthly, or yearly.
Template: transoffering
1. Query
PATH__NAME*

[[Page 38916]]

SELLER__CODE*
SELLER__DUNS*
POINT__OF__RECEIPT*
POINT__OF__DELIVERY*
SERVICE__INCREMENT*
TS__CLASS*
TS__TYPE*
TS__PERIOD*
START__TIME (of transmission services)
STOP__TIME (of transmission services)
POSTING__REF
TIME__OF__LAST__UPDATE
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 SELLER__CODEs, PATH__NAMEs__PORs, PODs, TS__xxx, and
the START__TIME/STOP__TIME specified in the query. The SALE__REF is a
value provided by the SELLER to identify the transmission service
product being sold. The ANC__SVC__REQ indicates all ancillary services
required for the specified transmission services. All Template elements
are defined in the Data Element Dictionary.

TIME__OF__LAST__UPDATE
SELLER__CODE
SELLER__DUNS
PATH__NAME
POINT__OF__RECEIPT
POINT__OF__DELIVERY
INTERFACE__TYPE
OFFER__START__TIME
OFFER__STOP__TIME
START__TIME
STOP__TIME
CAPACITY
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__WINDOW
TS__SUBCLASS
ANC__SVC__REQ
SALE__REF
POSTING__REF
CEILING__PRICE
OFFER__PRICE
PRICE__UNITS
SERVICE__DESCRIPTION (if null, then look at transserv)
NERC__CURTAILMENT__PRIORITY
OTHER__CURTAIMENT__PRIORITY
SELLER__NAME
SELLER__PHONE
SELLER__FAX
SELLER__EMAIL
SELLER__COMMENTS
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
SELLER__CODE
SELLER__DUNS
CONTROL__AREA
SERVICE__INCREMENT
ANC__SERVICE__TYPE
START__TIME
STOP__TIME
POSTING__REF
TIME__OF__LAST__UPDATE
2. Response
TIME__OF__LAST__UPDATE

[[Page 38917]]

SELLER__CODE
SELLER__DUNS
CONTROL__AREA
OFFER__START__TIME
OFFER__STOP__TIME
START__TIME
STOP__TIME
CAPACITY
SERVICE__INCREMENT
ANCILLARY__SERVICE__TYPE
SALE__REF
POSTING__REF
CEILING__PRICE
OFFER__PRICE
PRICE__UNITS
SERVICE__DESCRIPTION (if blank, then look at ancserv)
SELLER__NAME
SELLER__PHONE
SELLER__FAX
SELLER__EMAIL
SELLER__COMMENTS
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 SERVICE__INCREMENT,
TS__CLASS, TS__TYPE, TS__PERIOD, TS__SUBCLASS, TS__WINDOW,
NERC__CURTAIMENT__PRIORITY, and OTHER__CURTAIMENT__PRIORITY 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 PRICE__UNITS with this
Template.
Template: transserv
1. Query
TIME__OF__LAST__UPDATE
2. Response
TIME__OF__LAST__UPDATE
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__WINDOW
TS__SUBCLASS
CEILING__PRICE
PRICE__UNITS
SERVICE__DESCRIPTION
NERC__CURTAILMENT__PRIORITY
OTHER__CURTAILMENT__PRIORITY
TARIFF__REFERENCE
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 PRICE__UNITS with this Template.
Template: ancserv
1. Query
TIME__OF__LAST__UPDATE
2. Response
TIME__OF__LAST__UPDATE
SERVICE__INCREMENT
ANC__SERVICE__TYPE
CEILING__PRICE
PRICE__UNITS
SERVICE__DESCRIPTION
TARIFF__REFERENCE

[[Page 38918]]

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 CAPACITY__SCHEDULED,
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
PATH__NAME*
SELLER__CODE*
SELLER__DUNS*
CUSTOMER__CODE*
CUSTOMER__DUNS*
POINT__OF__RECEIPT*
POINT__OF__DELIVERY*
SERVICE__INCREMENT*
TS__CLASS*
TS__TYPE*
TS__PERIOD*
START__TIME
STOP__TIME
TIME__OF__LAST__UPDATE
ASSIGNMENT__REF
2. Response
TIME__OF__LAST__UPDATE
SELLER__CODE
SELLER__DUNS
PATH__NAME
POINT__OF__RECEIPT
POINT__OF__DELIVERY
CUSTOMER__CODE
CUSTOMER__DUNS
AFFILIATE__FLAG
START__TIME (start time of schedule)
STOP__TIME (stop time of schedule)
CAPACITY (reserved)
CAPACITY__SCHEDULED (total of energy scheduled for this customer for
this reservation for this hour)
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__WINDOW
TS__SUBCLASS
NERC__CURTAILMENT__PRIORITY
OTHER__CURTAILMENT__PRIORITY
ASSIGNMENT__REF (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 CAPACITY__CURTAILMENT, CURTAILMENT__REASON and
CURTAILMENT__OPTIONS. 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
PATH__NAME
SELLER__CODE*
SELLER__CODE
CUSTOMER__CODE*
CUSTOMER__DUNS*
POINT__OF__RECEIPT*
POINT__OF__DELIVERY*

[[Page 38919]]

List (list) is used to provide lists of valid names. The minimum
set of lists is LIST, SELLER__CODEs, PATHs, PORs, PODs,
SERVICE__INCREMENTs, TS__CLASSes, TS__TYPEs, TS__PERIODs,
NERC__CURTAILMENT__PRIORITY, OTHER__CURTAILMENT__PRIORITY,
ANCILLARY__SERVICE__TYPEs, CATEGORYs, and TEMPLATEs. These names may be
used to query information, post or request services.
Template: list
1. Query
LIST__NAME
TIME__OF__LAST__UPDATE
2. Response
TIME__OF__LAST__UPDATE
LIST__NAME
LIST__ITEM
LIST__ITEM__DESCRIPTION
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: TIME__STAMP, TEMPLATE,
ELEMENT__NAME, AND NEW__DATA. In this case the value of OLD__DATA in
not applicable.
Template: auditlog
1. Query
START__TIME (search against audit log)

[[Page 38920]]

STOP__TIME (search against audit log)
2. Response
ASSIGNMENT__REF or POSTING__REF
TIME__STAMP
TEMPLATE
ELEMENT__NAME (for data elements whose values have changed)
OLD__DATA
NEW__DATA
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.
CUSTOMER__CODE and CUSTOMER__DUNS 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, BID__PRICE, START__TIME, and
STOP__TIME.
For requesting transmission services which include multiple paths,
only the following fields may be redefined in a continuation record for
the transrequest Template: PATH__NAME. Supporting multiple paths is at
the discretion of the Provider.
The START__TIME and STOP__TIME indicate the requested period of
service.
When the request is received at the OASIS Node, the TSIP assigns a
unique ASSIGNMENT__REF 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
CONTINUATION__FLAG
SELLER__CODE (Primary or Reseller)
SELLER__DUNS
PATH__NAME
POINT__OF__RECEIPT
POINT____OF__DELIVERY
SOURCE
SINK
CAPACITY
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__SUBCLASS
STATUS__NOTIFICATION
START__TIME
STOP__TIME
BID__PRICE
PRECONFIRMED
ANC__SVC__LINK
POSTING__REF (Optionally set by Customer)
SALE__REF (Optionally set by Customer)
REQUEST__REF (Optionally set by Customer)
DEAL__REF (Optionally set by Customer)
CUSTOMER__COMMENTS
2. Response (acknowledgement)
RECORD__STATUS
CONTINUATION__FLAG
ASSIGNMENT__REF (assigned by TSIP)
SELLER__CODE
SELLER__DUNS
PATH__NAME

[[Page 38921]]

POINT__OF__RECEIPT
POINT__OF__DELIVERY
SOURCE
SINK
CAPACITY
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__SUBCLASS
STATUS__NOTIFICATION
START__TIME
STOP__TIME
BID__PRICE
PRECONFIRMED
ANC__SVC__LINK
POSTING__REF
SALE__REF
REQUEST__REF
DEAL__REF
CUSTOMER__COMMENTS
ERROR__MESSAGE
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: PATH__NAME, CAPACITY,
START__TIME, STOP__TIME, REASSIGNED__REF, REASSIGNED__CAPACITY,
REASSIGNED__START__TIME, AND REASSIGNED__STOP__TIME.
The AFFILIATE__FLAG will be set by the TSIP to indicate whether or
not the Customer is an affiliate of the Primary Provider. The
NEGOTIATED__PRICE__FLAG will be set by the TSIP to indicate whether the
OFFER__PRICE is higher, lower, or the same as the BID__PRICE.
Template: transstatus
1. Query
SELLER__CODE*
SELLER__DUNS*
SELLER__CODE*
CUSTOMER__DUNS*
PATH__NAME*
POINT__OF__RECEIPT*
POINT__OF__DELIVERY*
SERVICE__INCREMENT*
TS__CLASS*
TS__TYPE*
TS__PERIOD*
STATUS*
START__TIME (Beginning time of service)
STOP__TIME
START__TIME__QUEUED (Beginning time queue)
STOP__TIME__QUEUED
NEGOTIATED__PRICE__FLAG
ASSIGNMENT__REF
REASSIGNED__REF
SALE__REF
REQUEST__REF
DEAL__REF
TIME__OF__LAST__UPDATE
2. Response
CONTINUATION__FLAG
ASSIGNMENT__REF
SELLER__CODE
SELLER__DUNS
CUSTOMER__CODE
CUSTOMER__DUNS

[[Page 38922]]

AFFILIATE__FLAG (Set by TSIP)
PATH__NAME
POINT__OF__RECEIPT
POINT__OF__DELIVERY
SOURCE
SINK
CAPACITY (total reservation)
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__WINDOW
TS__SUBCLASS
NERC__CURTAILMENT__PRIORITY
OTHER__CURTAILMENT__PRIORITY
START__TIME
STOP__TIME
CEILING__PRICE
OFFER__PRICE
BID__PRICE
PRECONFIRMED
ANC__SVC__LINK
ANC__SVC__REQ
ALTERNATE__SERVICE__FLAG
POSTING__REF
SALE__REF
REQUEST__REF
DEAL__REF
NEGOTIATED__PRICE__FLAG (``L'' if Seller accepted Price is lower than
OFFER__PRICE in transoffering Template; ``H'' if higher; otherwise
blank)
STATUS=RECEIVED, QUEUED, STUDY, REBID, OFFER, ACCEPTED, REFUSED,
CONFIRMED, WITHDRAWN, DISPLACED, ANNULLED, RETRACTED
STATUS__NOTIFICATION
STATUS__COMMENTS
TIME__QUEUED
RESPONSE__TIME__LIMIT
TIME__OF__LAST__UPDATE
PRIMARY__PROVIDER__COMMENTS
SELLER__COMMENTS
CUSTOMER__COMMENTS
SELLER__NAME
SELLER__PHONE
SELLER__FAX
SELLER__EMAIL
CUSTOMER__NAME
CUSTOMER__PHONE
CUSTOMER__FAX
CUSTOMER__EMAIL
REASSIGNED__CAPACITY (Capacity from each previous transaction)
REASSIGNED__START__TIME
REASSIGNED__STOP__TIME
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, STATUS__COMMENTS, SELLER__COMMENTS, REASSIGNED__REF,
NEGOTIATED__PRICE__FLAG, ANC__SRV__REQ, REASSIGNED__START__TIME,
REASSIGNED__STOP__TIME, and REASSIGNED__CAPACITY. If not preconfirmed,
then the Seller can also change OFFER__PRICE.
Only the following fields may be redefined in a continuation record
for the transsell Template: REASSIGNED__CAPACITY, OFFER__PRICE,
REASSIGNED__REF, REASSIGNED__START__TIME, and REASSIGNED__STOP__TIME.
SELLER__CODE and SELLER__DUNS shall be determined from the
registered connection used to input the request.
The Seller may accept a reservation only when the BID__PRICE and
the OFFER__PRICE are the same.
Template: transsell
1. Input
CONTINUATION__FLAG

[[Page 38923]]

ASSIGNMENT__REF (Required)
OFFER__PRICE
STATUS= RECEIVED, STUDY, OFFER, ACCEPTED, REFUSED, ANNULLED, RETRACTED,
DISPLACED
STATUS__COMMENTS
OTHER__CURTAILMENT__PRIORITY (optional)
ANC__SVC__REQ
NEGOTIATED__PRICE__FLAG
SELLER__COMMENTS
RESPONSE__TIME__LIMIT
REASSIGNED__REF
REASSIGNED__CAPACITY (Previous capacity to be reassigned)
REASSIGNED__START__TIME
REASSIGNED__STOP__TIME
2. Response
RECORD__STATUS
CONTINUATION__FLAG
ASSIGNMENT__REF
OFFER__PRICE
STATUS= RECEIVED, STUDY, OFFER, ACCEPTED, REFUSED, ANNULLED, RETRACTED,
DISPLACED
STATUS__COMMENTS
OTHER__CURTAILMENT__PRIORITY
ANC__SVC__REQ
NEGOTIATED__PRICE__FLAG
SELLER__COMMENTS
RESPONSE__TIME__LIMIT
REASSIGNED__REF
REASSIGNED__CAPACITY (Previous capacity to be reassigned)
REASSIGNED__START__TIME
REASSIGNED__STOP__TIME
ERROR__MESSAGE
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 BID__PRICE, STATUS, STATUS__COMMENTS, ANC__SVC__LINK, and
CUSTOMER__COMMENTS data elements can be modified in this Template.
CUSTOMER__CODE and CUSTOMER__DUNS shall be determined from the
registered connection used to input the request.
The Customer must change the BID__PRICE to be equal to the
OFFER__PRICE for each record before the STATUS can be set to CONFIRMED.
Template: transcust
1. Input
CONTINUATION__FLAG
ASSIGNMENT__REF (Required)
REQUEST__REF
DEAL__REF
BID__PRICE
STATUS= REBID, CONFIRMED, WITHDRAWN
STATUS__COMMENTS
ANC__SVC__LINK
STATUS__NOTIFICATION If left blank, then original URL from the
transrequest will be used
CUSTOMER__COMMENTS
2. Response
RECORD__STATUS
CONTINUATION__FLAG
ASSIGNMENT__REF
REQUEST__REF
DEAL__REF
BID__PRICE
STATUS= REBID, CONFIRMED, WITHDRAWN
STATUS__COMMENTS
ANC__SVC__LINK
STATUS__NOTIFICATION
CUSTOMER__COMMENTS
ERROR__MESSAGE

[[Page 38924]]

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 REASSIGNED__REF 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.
CUSTOMER__CODE and CUSTOMER__DUNS shall be determined from the
registered connection used to input the request.
REASSIGNED__REF contains the ASSIGNMENT__REF of the original,
confirmed reservation that is being designated to the alternate points
of delivery/receipt. The Template allows for only one REASSIGNED__REF
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 REASSIGNED__REF).
Demand profiles associated with the designation of alternate POD/
POR may be submitted by additional records designating ``Y'' for
CONTINUATION__FLAG, and specifying the CAPACITY, START__TIME, and
STOP__TIME data elements corresponding to the MW demand being requested
over each time interval associated with the reservation. The CAPACITY,
START__TIME, and STOP__TIME 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:

SELLER__CODE (value from SELLER__CODE in reservation designated by
REASSIGNED__REF)
SELLER__DUNS (value from SELLER__DUNS in reservation designated by
REASSIGNED__REF)
ALTERNATE__SERVICE__FLAG = YES
OFFER__PRICE = S0
BID__PRICE = S0
CEILING__PRICE = S0
TS__CLASS = Non-Firm (or whatever the Provider designates)
REASSIGNED__CAPACITY = MW capacity submitted in CAPACITY field of
Template
REASSIGNED__START__TIME = time submitted in START__TIME field of
Template
REASSIGNED__STOP__TIME = time submitted in STOP__TIME field of Template
Template: transalt
1. Input
CONTINUATION__FLAG
PATH__NAME
POINT__OF__RECEIPT
POINT__OF__DELIVERY
SOURCE
SINK
PRECONFIRMED
CAPACITY (Must be less than or equal to original capacity reservation)
STATUS__NOTIFICATION
START__TIME (Valid only to hour and within the time of original
reservation)
STOP__TIME (Valid only to hour and within the time of original
reservation)
REQUEST__REF
DEAL__REF
REASSIGNED__REF (Assignment Reference for the Firm reservation being
used for request)
CUSTOMER__COMMENTS
2. Response (acknowledgment)
RECORD__STATUS
CONTINUATION__FLAG
ASSIGNMENT__REF (assigned by the TSIP)
SELLER__CODE (Primary)
SELLER__DUNS
PATH__NAME
POINT__OF__RECEIPT
POINT__OF__DELIVERY
SOURCE
SINK
PRECONFIRMED
ALTERNATE__SERVICE__FLAG (Defaulted to YES)
CAPACITY (Capacity requested)
STATUS__NOTIFICATION
START__TIME
STOP__TIME
REQUEST__REF

[[Page 38925]]

DEAL__REF
REASSIGNED__REF (Assignment Reference for the Firm reservation being
used for request)
ERROR__MESSAGE
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
ASSIGNMENT__REF in the response (acknowledgment) and enter the status
CONFIRMED as viewed in the transstatus Template.
SELLER__CODE and SELLER__DUNS 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, START__TIME, STOP__TIME,
REASSIGNED__REF, REASSIGNED__CAPACITY, REASSIGNED__START__TIME, and
REASSIGNED__STOP__TIME.
SELLER__CODE and SELLER__DUNS shall be determined from the
registered connection used to input the request.
Template: transassign
1. Input
CONTINUATION__FLAG
CUSTOMER__CODE
CUSTOMER__DUNS
PATH__NAME
POINT__OF__RECEIPT
POINT__OF__DELIVERY
SOURCE
SINK
CAPACITY
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__SUBCLASS
START__TIME
STOP__TIME
OFFER__PRICE
ANC__SVC__LINK (optional: filled in if assignment is different than
original transmission reservation)
POSTING__NAMES
REASSIGNED__REF
REASSIGNED__CAPACITY (Capacity being sold from each previous
assignment)
REASSIGNED__START__TIME
REASSIGNED__STOP__TIME
SELLERS__COMMENTS
2. Response (acknowledgement)
RECORD__STATUS
CONTINUATION__FLAG
ASSIGNMENT__REF (assigned by TSIP)
CUSTOMER__CODE
CUSTOMER__DUNS
PATH__NAME
POINT__OF__RECEIPT
POINT__OF__DELIVERY
SOURCE
SINK
CAPACITY (Total capacity being reassigned)
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__SUBCLASS
START__TIME
STOP__TIME
OFFER__PRICE
ANC__SVC__LINK
POSTING__NAME
REASSIGNED__REF
REASSIGNED__CAPACITY (Capacity being sold from each previous
assignment)
REASSIGNED__START__TIME
REASSIGNED__STOP__TIME

[[Page 38926]]

SELLER__COMMENTS
ERROR__MESSAGE
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.
SELLER__CODE and SELLER__DUNS shall be determined from the
registered connection used to input the request.
Template: transpost
1. Input
PATH__NAME
POINT__OF__RECEIPT
POINT__OF__DELIVERY
INTERFACE__TYPE
CAPACITY
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__WINDOW
TS__SUBCLASS
OTHER__CURTAILMENT__PRIORITY (optional)
ANC__SVC__REQ
START__TIME
STOP__TIME
OFFER__START__TIME
OFFER__STOP__TIME
SALE__REF
OFFER__PRICE
SERVICE__DESCRIPTION
SELLER__COMMENTS
2. Response (Acknowledgment)
RECORD__STATUS
POSTING__REF (Assigned by TSIP)
PATH__NAME
POINT__OF__RECEIPT
POINT__OF__DELIVERY
INTERFACE__TYPE
CAPACITY
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__WINDOW
TS__SUBCLASS
OTHER__CURTAILMENT__PRIORITY
ANC__SVC__REQ
START__TIME
STOP__TIME
OFFER__START__TIME
OFFER__STOP__TIME
SALE__REF
OFFER__PRICE
SERVICE__DESCRIPTION
SELLER__COMMENTS
ERROR__MESSAGE
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.
SELLER__CODE and SELLER__DUNS shall be determined from the
registered connection used to input the request.
Template: transupdate
1. Input
POSTING__REF (Must be provided)

[[Page 38927]]

CAPACITY (only if modified)
START__TIME (only if modified)
STOP__TIME (only if modified)
OFFER__START__TIME (only if modified)
OFFER__STOP__TIME (only if modified)
ANC__SVC__REQ (only if modified)
SALE__REF (only if modified)
OFFER__PRICE (only if modified)
SERVICE__DESCRIPTION (only if modified)
SELLER__COMMENTS (only if modified)
2. Response (acknowledgment)
RECORD__STATUS
POSTING__REF
CAPACITY
START__TIME
STOP__TIME
OFFER__START__TIME
OFFER__STOP__TIME
ANC__SVC__REQ
SALE__REF
OFFER__PRICE
SERVICE__DESCRIPTION
SELLER__COMMENTS
ERROR__MESSAGE
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 STATUS__NOTIFICATION as for
transrequest. The reference Data Elements are optional.
CUSTOMER__CODE and CUSTOMER__DUNS shall be determined from the
registered connection used to input the request.
Template: ancrequest
1. Input
SELLER__CODE
SELLER__DUNS
CONTROL__AREA
CAPACITY
SERVCIE__INCREMENT
ANC__SERVICE__TYPE
STATUS__NOTIFICATION
START__TIME
STOP__TIME
BID__PRICE
PRECONFIRMED
POSTING__REF (Optionally Set by Customer)
SALE__REF (Optionally Set by Customer)
REQUEST__REF (Optionally Set by Customer)
DEAL__REF (Optionally Set by Customer)
CUSTOMER__COMMENTS
2. Response (acknowledgment)
RECORD__STATUS
ASSIGNMENT__REF (assigned by TSIP)
SELLER__CODE
SELLER__DUNS
CONTROL__AREA
CAPACITY
SERVICE__INCREMENT
ANC__SERVCIE__TYPE
STATUS__NOTIFICATION
START__TIME
STOP__TIME
BID__PRICE
PRECONFIRMED

[[Page 38928]]

POSTING__REF
SALE__REF
REQUEST__REF
DEAL__REF
CUSTOMER__COMMENTS
ERROR__MESSAGE
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 AFFILIATE__FLAG 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
SELLER__CODE*
SELLER__DUNS*
CUSTOMER__CODE*
CUSTOMER__DUNS*
CONTROL__AREA
SERVICE__INCREMENT
ANC__SERVICE__TYPE
STATUS
START__TIME
STOP__TIME
START__TIME__QUEUED
STOP__TIME__QUEUED
ASSIGNMENT__REF
SALE__REF
REQUEST__REF
DEAL__REF
TIME__OF__LAST__UPDATE (only if TIME__OF__LAST__UPDATE is posted by
record)
2. Response
ASSIGNMENT__REF
SELLER__CODE
SELLER__DUNS
CUSTOMER__CODE
CUSTOMER__DUNS
AFFILIATE__FLAG (Set by TSIP)
CONTROL__AREA
CAPACITY
SERVICE__INCREMENT
ANC__SERVICE__TYPE
START__TIME
STOP__TIME
CEILING__PRICE
OFFER__PRICE
BID__PRICE
PRECONFIRMED
POSTING__REF
SALE__REF
REQUEST__REF
DEAL__REF
NEGOTIATED__PRICE__FLAG (``L'' if Seller accepted Price is lower than
OFFER__PRICE in ancoffering Template; ``H'' if higher; otherwise blank)
STATUS=QUEUED, RECEIVED, REBID, OFFER, ACCEPTED, REFUSED, CONFIRMED,
WITHDRAWN, ANNULLED, RETRACTED
STATUS__NOTIFICATION
STATUS__COMMENTS
TIME__QUEUED
RESPONSE__TIME__LIMIT
TIME__OF__LAST__UPDATE
PRIMARY __PROVIDER__COMMENTS
SELLER__COMMENTS
CUSTOMER__COMMENTS
SELLER__NAME

[[Page 38929]]

SELLER__PHONE
SELLER__FAX
SELLER__EMAIL
CUSTOMER__NAME
CUSTOMER__PHONE
CUSTOMER__FAX
CUSTOMER__EMAIL
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.
SELLER__CODE and SELLER__DUNS shall be determined from the
registered connection used to input the request.
Template: ancsell
1. Input
ASSIGNMENT__REF (Required)
OFFER__PRICE
STATUS=RECEIVED, OFFER, ACCEPTED, REFUSED
STATUS__COMMENTS
SELLER__COMMENTS
2. Response (acknowledgment)
RECORD__STATUS
ASSIGNMENT__REF
OFFER__PRICE
STATUS=RECEIVED, OFFER, ACCEPTED, REFUSED
STATUS__COMMENTS
NEGOTIATED__PRICE__FLAG
RESPONSE__TIME__LIMIT
SELLER__COMMENTS
ERROR__MESSAGE
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 BID__PRICE to be equal to the
OFFER__PRICE before the STATUS can be set to CONFIRMED.
customer__CODE and CUSTOMER__DUNS shall be determined from the
registered connection used to input the request.
Template: anccust
1. Input
ASSIGNMENT__REF (Required)
REQUEST__REF
DEAL--REF
BID__PRICE
STATUS=REBID, CONFIRMED, WITHDRAWN
STATUS__COMMENTS
STATUS__NOTIFICATION (If left blank, then the original URL from the
ancrequest will be used
CUSTOMER__COMMENTS
2. Response (Acknowledgment)
RECORD__STATUS
ASSIGNMENT__REF
REQUEST__REF
DEAL__REF
BID__PRICE
STATUS=REBID, CONFIRMED, WITHDRAWN
STATUS__COMMENTS
STATUS__NOTIFICATION
CUSTOMER__COMMENTS
ERROR__MESSAGE
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.

[[Page 38930]]

SELLER__CODE and SELLER__DUNS shall be determined from the
registered connection used to input the request.
Template: ancpost
1. Input
CONTROL__AREA
SERVICE__DESCRIPTION
CAPACITY
SERVICE__INCREMENT
ANC__SERVICE__TYPE
START__TIME
STOP__TIME
OFFER__START__TIME
OFFER__STOP__TIME
SALE__REF
OFFER__PRICE
SELLER__COMMENTS
2. Response (acknowledgement)
RECORD__STATUS
POSTING__REF (Assigned by TSIP)
CONTROL__AREA
SERVICE__DESCRIPTION
CAPACITY
SERVICE__INCREMENT
ANC__SERVICE__TYPE
START__TIME
STOP__TIME
OFFER__START__TIME
OFFER__STOP__TIME
SALE__REF
OFFER__PRICE
SELLER__COMMENTS
ERROR__MESSAGE
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.
SELLER__CODE and SELLER__DUNS shall be determined from the
registered connection used to input the request.
Template: ancupdate
1. Input
POSTING__REF (Required)
CAPACITY (only if modified)
SERVICE__DESCRIPTION (only if modified)
START__TIME (only if modified)
STOP__TIME (only if modified)
OFFER__START__TIME (only if modified)
OFFER__STOP__TIME (only if modified)
SALE__REF (only if modified)
OFFER__PRICE (only if modified)
SELLER__COMMENTS (only if modified)
2. Response (acknowledgment)
RECORD__STATES
POSTING__REF
CAPACITY
SERVICE__DESCRIPTION
START__TIME
STOP__TIME
OFFER__START__TIME
OFFER__STOP__TIME
SALE__REF
OFFER__PRICE
SELLER__COMMENTS
ERROR__MESSAGE
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.

[[Page 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.
CUSTOMER__CODE and CUSTOMER__DUNS shall be determined from the
registered connection used to input the request.
Template: messagepost
1. Input
SUBJECT
CATEGORY
VALID__FROM__TIME
VALID__TO__TIME
MESSAGE (must be specified)
2. Response (acknowledgment)
RECORD__STATUS
POSTING__REF (assigned by information provider)
SUBJECT
CATEGORY
VALID__FROM__TIME
VALID__TO__TIME
MESSAGE
ERROR__MESSAGE
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
CUSTOMER__CODE
CUSTOMER__DUNS
POSTING__REF
CATEGORY
VALID__FROM__TIME
VALID__TO__TIME
TIME__POSTED
2. Response
CUSTOMER__CODE
POSTING__REF
SUBJECT
CATEGORY
VALID__FROM__TIME
VALID__TO__TIME
TIME__POSTED
CUSTOMER__NAME
CUSTOMER__PHONE
CUSTOMER__FAX
CUSTOMER__EMAIL
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
POSTING__REF number is used to determine which message.
CUSTOMER__CODE and CUSTOMER__DUNS shall be determined from the
registered connection used to input the request.
Template: messagedelete
1. Input
POSTING__REF
2. Response (acknowledgment)
RECORD__STATUS
POSTING__REF
ERROR__MESSAGE

[[Page 38932]]

4.3.11.4 Personnel Transfers (personnel)
Template: personnel
1. Query
TIME__OF__LAST__UPDATE
START__TIME__POSTED
STOP__TIME__POSTED
2. Response
POSTING__NAME
EMPLOYEE__NAME
FORMER__POSITION
FORMER__COMPANY
FORMER__DEPARTMENT
NEW__POSITION
NEW__COMPANY
NEW__DEPARTMENT
DATE__TIME__EFFECTIVE
DATE__TIME__POSTED
TIME__OF__LAST__UPDATE
4.3.11.5 Discretion (discretion)
Template: discretion
1. Query
START__TIME__POSTED
STOP__TIME__POSTED
STOP__TIME
SERVICE__TYPE
SERVICE__NAME
TIME__OF__LAST__UPDATE
2. Response
POSTING__NAME
RESPONSIBLE__PARTY__NAME (name of person granting discretion)
SERVICE__TYPE (ancillary or transmission)
SERVICE__NAME (make consistent with offering Templates)
TARIFF__REFERENCE
START__TIME
STOP__TIME
DISCRETION__DESCRIPTION
TIME__POSTED
TIME__OF__LAST__UPDATE
4.3.11.6 Standards of Conduct (stdconduct)
Template: stdconduct
1. Query
START__TIME__POSTED
STOP__TIME__POSTED
TIME__OF__LAST__UPDATE
2. Response
POSTING__NAME
RESPONSIBLE__PARTY__NAME
STANDARDS__OF__CONDUCT__ISSUES
TIME__POSTED
TIME__OF__LAST__UPDATE

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 PATH__NAME ``W/AAAA/PATH-ABC//'' for April 10, 1996
from 8 a.m. to 3 p.m. (Note that the PATH__NAME consists of a
REGION__CODE, PRIMARY__PROVIDER__CODE, PATH__CODE, and an
OPTIONAL__CODE, 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

[[Page 38933]]

2. Response Data
REQUEST-STATUS=200 (Successful)
TIME__STAMP=19960409113526PD
VERSION=1.2
TEMPLATE=transoffering
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AAAA
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=14
COLUMN__HEADERS=TIME__OF__LAST__UPDATE, SELLER__CODE, SELLER__DUNS,
PATH__NAME, POINT__OF__RECEIPT, POINT__OF__DELIVERY, INTERFACE__TYPE,
OFFER__START__TIME, OFFER__STOP__TIME, START__TIME, STOP__TIME,
CAPACITY, SERVICE__INCREMENT, TS__CLASS, TS__TYPE,TS__PERIOD,
TS__SUBCLASS, SALE__REF, POSTING__REF, CEILING__PRICE, OFFER__PRICE,
PRICE__UNITS, SERVICE__DESCRIPTION, SELLER__NAME, SELLER__PHONE,
SELLER__FAX, SELLER-EMAIL, SELLER__COMMENTS
19960409030000PD,WXYZ, 987654321,W/AAA/ABC//,N/A,N/A,E,
19960402080000PD,
19960410080000PD,19960410080000PD,19960410090000PD,300, HOURLY, FIRM,
POINT__T0__POINT, OFF__PEAK, 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, POINT__T0__POINT. OFF__PEAK, 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,
POINT__T0__POINT, OFF__PEAK, 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, POINT__T0__POINT, OFF__PEAK, 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, POINT__T0__POINT, OFF__PEAK, 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, POINT__T0__POINT, OFF__PEAK, 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,
FIRMPOINT__T0__POINT, OFF__PEAK, 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, POINT__T0__POINT, OFF__PEAK ,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,
POINT__T0__POINT, OFF__PEAK, 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, POINT__ TO__ POINT, OFF__PEAK,
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 fetch__http 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 fetch__http 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

[[Page 38934]]

TIME__STAMP=19960410114702PD
VERSION-1.2
TEMPLATE=schedule
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AAAA
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=5
COLUMN__HEADERS=TIME__OF__LAST__UPDATE, SELLER__CODE. SELLER__DUNS,
PATH__NAME, POINT__OF__RECEIPT. POINT__OF__DELIVERY, CUSTOMER__CODE.
CUSTOMER__DUNS, AFFILIATE__FLAG, START__TIME. STOP__TIME, CAPACITY,
CAPACITY__SCHEDULED, SERVICE__INCREMENT, TS__CLASS, TS__TYPE,
TS__PERIOD, TS__SUBCLASS, ASSIGNMENT__REF
1996049030000pd.wxyz.0987654321. W/AAA/ABC//.BBB.CCC.
WXYZAA.0987654322.Y.19960410100000PD. 19960410110000PD.300.300. HOURLY,
FIRM, POINT__ TO__ POINT, OFF__ PEAK, N/A, 856743
. . .
. . .
1996049030000pd.wxyz.0987654321. W/AAA/ABC//.BBB.CCC.WXYZAA.
0987654322.Y. 19960410130000PD. 19960410140000PD.300.300. HOURLY, FIRM,
POINT__ TO__ POINT, OFF__ PEAK, N/A, 856743
1996049030000pd.wxyz. 0987654321.W/AAA/ABC//.BBB.CCC.
WXYZAA.0987654322.Y. 19960410140000PD. 19960410150000PD.300.300.
HOURLY, FIRM, POINT__ TO__ POINT, OFF__ 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 FETCH__ HTTP program to
send a file to the OASIS node of the Primary Provider.
1. Input:
VERSION-1.2
TEMPLATE=transpost
OUTPUT__ FORMAT=DATA
PRIMARY__ PROVIDER__ CODE=AAAA
PRIMARY__ PROVIDER__ DUNS=123456789
DATA__ ROWS=1
COLUMN__HEADERS=PATH__NAME, POINT__OF__DELIVER, INTERFACE__TYPE,
CAPACITY, SERVICE__INCREMENT, TS__CLASS, TS__TYPE, TS__PERIOD,
TS__SUBCLASS, START__TIME, STOP__TIME, OFFER__START__ TIME,
OFFER__STOP__ TIME, SALE__REF. OFFER__PRICE, SERVICE__DESCRIPTION,
SELLER__COMMENTPF
WXYZ.987654321.W/AAA/ABC//.N/A,N/A.E.150, HOURLY, FIRM, POINT__ TO__
POINT, OFF__ PEAK, N/A/.19960402080000PD, 19960410080000PD,
19960410080000PD, 199604101500PD, A123.90.N/A, ``As Joe said, ````It is
a good buy''''''
FETCH__ HTTP Command to send posting
S fetch__ http http//(OASIS Node name)/OASIS/abcd/data/transrequest-
fc:/OASIS/abcd/upload/post.txt
2. Response Data
REQUEST-STATUS=200(Successful)
TIME__ STAMP=19960409113526PD
VERSION-1.2
TEMPLATE=transpost
OUTPUT__ FORMAT=DATA
PRIMARY__PROVIDER__ CODE=AAAA
PRIMARY__ PROVIDER__ DUNS=123456789
DATA__ ROWS=1
COLUMN__HEADERS=RECORD__STATUS, PATH__NAME, POINT__OF__RECEIPT,
POINT__OF__DELIVER, INTERFACE__TYPE, CAPACITY, SERVICE__INCREMENT,
TS__CLASS, TS__TYPE, TS__PERIOD, TS__SUBCLASS, START__TIME, STOP__TIME,
OFFER__START__TIME, OFFER__STOP__ TIME__TIME, SALE__REF, OFFER__PRICE,
SERVICE__DESCRIPTION, SELLER__COMMENTS, ERROR__MESSAGE
200.WXYZ.987654321, W/AAA/ABC//,N/A, N/A. E.150, HOURLY, FIRM,
POINT__TO__POINT, OFF__PEAK, 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''
CUSTOMER__CODE=``BestE''
CAPACITY=150
TS__CLASS=``FIRM''
START__TIME=``1996050708000000PD''

[[Page 38935]]

STOP__TIME=``1996050717000000PD''
BID__PRICE=``$1.00''
The Information Provider assigns ASSIGNMENT__REF=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
ASSIGNMENT__REF=5001 when the request for purchase is made and is shown
in the acknowledgment.

TEMPLATE=``transrequest''
CUSTOMER__CODE=``BestE''
CAPACITY=120
TS__CLASS=``NON-FIRM''
START__TIME=``1996050715000000PD''
STOP__TIME=``1996050721000000PD''
BID__PRICE=``$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''
SELLER__CODE=``BestE''
CAPACITY=100
TS__CLASS=``NON-FIRM''
START__TIME=``1996050708000000PD''
STOP__TIME=``1996050721000000PD''
SALE__REF=``BEST100''
OFFER__PRICE=.90
SELLER__COMMENTS=``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''
CUSTOMER__CODE=``Whlsle''
SELLER__CODE=``BestE''
CAPACITY=100
TS__CLASS=``NON-FIRM''
START__TIME=``1996050708000000PD''
STOP__TIME=``1996050721000000PD''
SALE__REF=``BEST100''
DEAL__REF=``WPC100''
BID__PRICE=.90
CUSTOMER__COMMENTS=``Only need service until 6 p.m.''
The Information Provider provides the ASSIGNMENT__REF=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''
CUSTOMER__CODE=``Whlsle''
SELLER__CODE=``BestE''
ASSIGNMENT__REF=5002
STATUS=``Accepted''
REASSIGNED__REF1=5000
REASSIGNED__CAPACITY1=100
REASSIGNED__START__TIME1=``199605070800PD''
REASSIGNED__STOP__TIME1=``199605071700PD''
REASSIGNED__REF2=5001
REASSIGNED__CAPACITY2=100
REASSIGNED__START__TIME2=``199605071700PD''
REASSIGNED__STOP__TIME2=``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 ASSIGNMENT__REF by the OASIS node.
Only the following fields may be redefined in a continuation record
for the transrequest Template: CAPACITY, START__TIME, STOP__TIME.
Specification of any values corresponding to COLUMN__HEADERs other than
CAPACITY, START__TIME, and STOP__TIME will be ignored, however commas
must be included to properly align the CAPACITY, START__TIME and
STOP__TIME fields.
Input:
VERSION=1.2

[[Page 38936]]

TEMPLATE=transrequest
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AEP
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=7
COLUMN__HEADERS=CONTINUATION__FLAG, SELLER__CODE, SELLER__DUNS,
PATH__NAME, POINT__OF__RECEIPT. POINT__OF__DELIVERY, SOURCE, SINK,
CAPACITY, SERVICE__INCREMENT, TS__CLASS, TS__TYPE, TS__PERIOD.
TS__SUBCLASS, STATUS__NOTIFICATION, START__TIME, STOP__TIME,
BID__PRICE. PRECONFIRMED, ANC__SVC__LINK, POSTING__REF, SALE__REF,
REQUEST__REF, DEAL__REF, CUSTOMER__COMMENTS
N. AEP, 123456789, ABC/XY, CE, MECS...35, DAILY, FIRM,
POINT__TO__POINT, OFF__PEAK, 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.
POINT__TO__POINT, OFF__PEAK, 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
POINT__TO__POINT, OFF__PEAK, 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:
REQUEST__STATUS=200
TIME__STAMP=19970422160523ES
TEMPLATE=transrequest
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AEP
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=7
COLUMN__HEADERS=RECORD__STATUS. CONTINUATION__FLAG, SELLER__CODE.
SELLER__DUNS. PATH__NAME. POINT__OF__RECEIPT. POINT__OF__DELIVERY.
SOURCE, SINK, CAPACITY, SERVICE__INCREMENT. TS__CLASS. TS__TYPE.
TS__PERIOD. TS__SUBCLASS. STATUS__NOTIFICATION. START__TIME.
STOP__TIME. BID__PRICE. PRECONFIRMED. ANC__SVC__LINK. POSTING__REF.
SALE__REF. REQUEST__REF. DEAL__REF, CUSTOMER__COMMENTS.
ERROR__MESSAGE
200. N. AEP. 123456789. ABC/XY. CE, MECS...35, DAILY. FIRM.
POINT__TO__POINT. OFF__PEAK, 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.
POINT__TO__POINT. OFF__PEAK. 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,
POINT__TO__POINT, OFF__PEAK, 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 ASSIGNMENT__REF=7019,
and Hourly Non-Firm in amount of 10 MW from 08:00 to 20:00 on 4/23
under ASSIGNMENT__REF=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 (ASSIGNMENT__REF=7880) with the balance taken up by
the Firm reservation (ASSIGNMENT__REF=7019).
The only fields allowed in ``continuation'' records for transsell
Template are REASSIGNED__REF, REASSIGNED__CAPACITY,
REASSIGNED__START__TIME, and REASSIGNED__STOP__TIME. Price may not be
negotiated for each ``segment'' in a capacity profile.
Input:
VERSION=1.2
TEMPLATE=transsell
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AEP

[[Page 38937]]

PRIMARY__PROVIDER__DUNS=123456789
DATA__ROW=3
COLUMN__HEADERS=RECORD__STATUS, CONTINUATION__FLAG, ASSIGNMENT__REF.
OFFER__PRICE. STATUS. STATUS__COMMENTS. ANC__SVC__LINK.
SELLER__COMMENTS. REASSIGNED__REF. REASSIGNED__CAPACITY.
REASSIGNED__START__TIME. REASSIGNED__STOP__TIME 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
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AEP
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROW=3
COLUMN__HEADERS=RECORD__STATUS. CONTINUATION__FLAG, ASSIGNMENT__REF.
OFFER__PRICE. STATUS. STATUS__COMMENTS. ANC__SVC__LINK.
SELLER__COMMENTS. REASSIGNED__REF. REASSIGNED__CAPACITY.
REASSIGNED__START__TIME. REASSIGNED__STOP__TIME, ERROR__MESSAGES 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 ASSIGNMENT__REF=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, START__TIME,
STOP__TIME, REASSIGNED__REF, REASSIGNED__CAPACITY,
REASSIGNED__START__TIME, and REASSIGNED__STOP__TIME.
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 CUSTOMER__NAME and SELLER__NAME were used to convey user
names for subsequent resolution of contact information from user
registration.
Input:
VERSION=1.2
TEMPLATE=transassign
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AEP
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=2
COLUMN__HEADERS=CONTINUATION__FLAG, CUSTOMER__CODE, CUSTOMER__DUNS,
PATH__NAME, POINT__OF__RECEIPT, POINT__OF__DELIVERY, SOURCE, SINK,
CAPACITY, SERVICE__INCREMENT, TS__CLASS, TS__TYPE, TS__PERIOD,
TS__SUBCLASS, START__TIME, STOP__TIME, OFFER__PRICE, SALE__REF,
POSTING__NAME, REASSIGNED__REF, REASSIGNED__CAPACITY,
REASSIGNED__START__TIME, REASSIGNED__STOP__TIME,
SELLER__COMMENTS
N. Resler, 456123789, Cust. 987654321..CE. VP...10. HOURLY. NON-FIRM,
POINT__TO__POINT, OFF__PEAK, 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:
REQUEST__STATUS=200
TIME__STAMP=19970422144520ES
VERSION=1.2
TEMPLATE=transassign
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AEP
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=2
COLUMN__HEADERS=RECORD__STATUS, CONTINUATION__FLAG, ASSIGNMENT__REF,
SELLER__CODE, SELLER__DUNS, CUSTOMER__CODE, CUSTOMER__DUNS,
AFFILIATE__FLAG, PATH__NAME, POINT__OF__RECEIPT, POINT__OF__DELIVERY,
SOURCE, SINK, CAPACITY, SERVICE__INCREMENT, TS__CLASS, TS__TYPE,
TS__PERIOD, TS__SUBCLASS, START__TIME, STOP__TIME, OFFER__PRICE,
SELLER__NAME, CUSTOMER__NAME, TIME__QUEUED,

[[Page 38938]]

SALE__REF, REASSIGNED__REF, REASSIGNED__CAPACITY,
REASSIGNED__START__TIME, REASSIGNED__STOP__TIME, SELLER__COMMENTS,
ERROR__MESSAGE
200. N. 8207, Rseler, 456123789, Cust. 987654321, N., CE. VP...10,
HOURLY, FIRM, POINT__TO__POINT, OFF__PEAK, 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, START__TIME,
STOP__TIME, REASSIGNED__REF, REASSIGNED__CAPACITY,
REASSIGNED__START__TIME, and REASSIGNED__STOP__TIME (price fields are
debatable).
Input:

Response:
REQUEST__STATUS=200
TIME__STAMP=19970423040523ES
TEMPLATE=transstatus
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AEP
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=11
COLUMN__HEADERS= CONTINUATION__FLAG, ASSIGNMENT__REF, SELLER__CODE,
SELLER__DUNS, CUSTOMER__CODE, CUSTOMER__DUNS, AFFILIATE__FLAG,
PATH__NAME, POINT__OF__RECEIPT, POINT__OF__DELIVERY, SOURCE, SINK,
CAPACITY, SERVICE__INCREMENT, TS__CLASS, TS__TYPE, TS__PERIOD,
TS__SUBCLASS, START__TIME, STOP__TIME, CEILING__PRICE, OFFER__PRICE,
BID__PRICE, PRECONFIRMED, ANC__SVC__LINK, ALTERNATE__SERVICE__FLAG,
POSTING__REF, SALE__REF, REQUEST__REF, DEAL__REF,
NEGOTIATED__PRICE__FLAG, STATUS, STATUS__COMMENTS, TIME__QUEUED,
TIME__OF__LAST__UPDATE, PRIMARY__PROVIDER__COMMENTS, SELLER__COMMENTS,
CUSTOMER__COMMENTS, SELLER__NAME, SELLER__PHONE, SELLER__FAX,
SELLER__EMAIL, CUSTOMER__NAME, CUSTOMER__PHONE, CUSTOMER__FAX,
CUSTOMER__EMAIL, REASSIGNED__REF, REASSIGNED__CAPACITY,
REASSIGNED__START__TIME, REASSIGNED__STOP__TIMES
N. 8207, Rseler, 456123789. ACust. 987654321. N..CE. VP...10, HOURLY,
FIRM, POINT__TO__POINT, OFF__PEAK, 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, [email protected]. 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, POINT__TO__POINT, OFF__PEAK, 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,[email protected], 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, POINT__TO__POINT, OFF__PEAK, 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, [email protected].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, POINT__TO__POINT, OFF__PEAK, N/A, 19970424040000ES,
19970424160000ES, 2.00, 2.50, 6.20, N.....CONFIRMED,,
19970422160523ES..Bid price refused, Negotiated OFFER__PRICE accepted,
Joe Smith, (888)-123-4567, (888)-123-1231, [email protected], 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 OFFER__PRICE 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 OFFER__PRICE to the BID__PRICE.

[[Page 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 OFFER__PRICE officially
becomes the terms of the reservation.
4.4.6.2 Negotiations without Preconfirmation
a. The Customer submits a transmission reservation request with the
BID__PRICE 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 BID__PRICE is too low, sets the
OFFER__PRICE to the price he wants, and sets the STATUS to OFFER via
the transsell Template.
d. The Customer agrees to the OFFER__PRICE, sets the BID__PRICE
equal to the OFFER PRICE, and sets the STATUS to CONFIRMED via the
transcust Template.
e. The OFFER__PRICE 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
BID__PRICE 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 STATUS via the transsell
Template to one of the following: RECEIVED, STUDY, ACCEPTED, OFFER, or
REFUSED.
c. The Seller determines that the BID__PRICE is too low, sets the
OFFER__PRICE to the desired value, and sets the STATUS to OFFER via the
transsell Template.
d. The Customer responds to the new OFFER__PRICE with an updated
BID__PRICE and sets the STATUS to REBID for re-evaluation by the
Seller.
e. The Seller determines that the BID__PRICE now is acceptable and
sets the STATUS to ACCEPTED via the transsell Template. The transition
to ACCEPTED state requires the OFFER__PRICE to be set to the
BID__PRICE: accepting a reservation with an OFFER__PRICE different from
BID__PRICE would require the STATUS be set to OFFER rather than
ACCEPTED (see item c).
f. The Customer agrees to the OFFER__PRICE and sets the STATUS to
CONFIRM via the transcust Template.
g. The OFFER__PRICE 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
BID__PRICE 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 BID__PRICE is too low, sets
OFFER__PRICE to his desired value, and sets STATUS to OFFER via the
transsell Template.
d. The Customer responds to OFFER__PRICE with updated BID__PRICE
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
BID__PRICE 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 BID__PRICE is too low, sets the
OFFER__PRICE to his desired value, and sets the STATUS to OFFER via the
transsell Template.
d. The Customer responds to the OFFER__PRICE with an updated
BID__PRICE and sets the STATUS to REBID for re-evaluation by Seller.
e. The Seller determines that the BID__PRICE is still too low, sets
the OFFER__PRICE 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.

[[Page 38940]]

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).
[GRAPHIC] [TIFF OMITTED] TR20JY98.003

A Provider account shall be considered to be down, and downtime
shall be accumulated, upon occurrence of any of the following:

[[Page 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.

[[Page 38942]]

Appendix A--Data Element Dictionary

Version 1.2

May 27, 1998

--------------------------------------------------------------------------------------------------------------------------------------------------------
Field format: minimum characters (type
Data dictionary element name Alias of ASCII) maximum characters Restricted values Definition of data element
--------------------------------------------------------------------------------------------------------------------------------------------------------
AFFILIATE__FLAG................... AFFLAG................ 1(ALPHANUMERIC)3....................... Valid Values......... Set to YES if customer is an
YES.................. affiliate of the provider.
NO...................
ANC__SERVICE__TYPE................ 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)
NAC__SVC__LINK.................... ANCSVCLINK............ 1(ALPHANUMERIC)300..................... Formatted string as The method for linking
follows: ancillary services to a
SC:(AA); RV: (AA); transmission service
RF: request. The provider and
(AA[:xxx[:yyy[:nnn]]] capacity of each ancillary
); service is identified using
EL: the formated string:
(AA[:xxx[:yyy[:nnn]]] SC:(AA); RV:(AA);
); RI:[:xxx[:yyy[:nnn]]]); El:
SP: (AA[:xxx[:yyy[:nnn]]]);
(AA[:xxx[:yyy[:nnn]]] SP:(AA[:xxx[:yyy[:nnn]]]);
); [Registered):(AA[:xxx[:yyy[:
SU: nnn]]])
(AA[:xxx[:yyy[:nnn]]] where AA is the appropriate
); PRIMARY__PROVIDER__CODE,
(Registered): SELLER__CODE; or
(AA[:xxx[:yyy[:nnn]] CUSTOMER__CODE, 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
ANC__SVC__TYPE: 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.

[[Page 38943]]

The terms ``yyy'' and
``nnn'' are subordinate to
the xxx type of ``AR'' yyy
represents the ancillary
services reservation number
(ASSIGNMENT__REF) 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
ANC__SVC__REQ..................... ANCSVCREQ............. 1(ALPHANUMERIC)100..................... EI: (M.R.O.U); SP; Ancillary services required
(M.R.O.U);. for a transmission services
SU: (M.R.O.U); offering. The appropriate
RV: (M.R.O.U): letter (M.R.O.U) will be
RE: (M.R.O.U); assigned to each of the six
SC: (M.R.O.U): Proforma FERC ancillary
(registered): services (see
(M.R.O.U) ANC__SERVICE__TYPE), 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.
ALTERNATE__SERVICE__FLAG.......... 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.
ASSIGNMENTU__REF.................. 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
START__TIME to an
STOP__TIME.
BID__PRICE........................ BIDPR................. 1(NUMERIC)5 +``,'' + 2(NUMERIC)12...... Positive number with The current bid price of a
2 decimals. Service in dollars and
cents. Used by Customers to
designate a price being
bid.
CAPACITY.......................... CAP................... 1(NUMERIC)12........................... Non-negative number Transfer capability is the
in units of MW. 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.
CAPACITY__CURTAILED............... CAPCUR................ 1(NUMERIC)12........................... Non-negative number The amount of transfer
in units of MW. capability curtailed by the
Primary provider for
emergency reasons.
CAPACITY__SCHEDULED............... CAPSCH................ 1(NUMERIC)12........................... Non-negative number Transfer capability
in units of MW. scheduled on each path.

[[Page 38944]]

CATEGORY.......................... CAT................... 1(ALPHANUMERIC)25...................... Valid name from A name to be used to
CATEGORY in LIST categorize messages. Valid
Template. names would include:
Disocunt, Want-Ad,
Curtailment, Outage, Oasis
Maint Notice.
CEILING__PRICE.................... CEILPR................ 1(NUMERIC)5 + ``.'' + 2(NUMERIC)2...... Positive number with Ceiling price of the Service
2 decimals. as entered by the
Transmission Provider.
COLUMN__HEADERS................... HEADERS............... 1(ALPHANUMERIC) Limited to all the Headers surrounded Example: COLUMN__HEADER=
elements names in one Template. with A and separated APATH__NAME'',
by commas. Limited ``POINT__OF__RECEIPT'',
to valid Template POINT__ OF__DELIVERY'',
element names. Must ``SOURCE'', ``SINK''.
use full element
name and not alias.
CONTINUATION__FLAG................ CONT.................. 1(ALPHANUMERIC)1....................... ``Y'' OR ``N''....... Indicates whether or not
this record is a
continuation from the
previous record.
CONTROL__AREA..................... AREA.................. 1(ALPHANUMERIC)20...................... Valid name of a A part of the power system
control area. with metered tie lines and
capable of matching
generation and load while
meeting scheduled
interchange. Location of
Ancillary Services is my
CONTROL__AREA.
CURTAILMENT__OPTIONS.............. CUROPT................ 1(ALPHANUMERIC)80...................... Free form text....... Customer options, if any, to
avoid curtailment.
CURTAILMENT__PROCEDURES........... CURPROC............... 1(ALPHANUMERIC)80...................... Free form text....... Curtailment procedures to be
followed in the event of a
curtailment.
CURTAILMENT__REASON............... CURREAS............... 1(ALPHANUMERIC)80...................... Free form text....... Reason for curtailment of
service.
CUSTOMER__CODE.................... CUST.................. 1(ALPHANUMERIC)6....................... Unique value, Any entity (or its
registered on designated agent) that is
TSIN.COM. eligible to view OASIS
information, to execute a
service agreement, and/or
to receive transmission
service.
CUSTOMER__COMMENTS................ CUSTCOM............... 1(ALPHANUMERIC)80...................... Free-form text....... Informative text.
CUSTOMER__DUNS.................... CUSTDUNS.............. 9(NUMERIC)9............................ Unique DUNS number... Unique DUNS number for a
Customer.
CUSTOMER__EMAIL................... CUSTEMAIL............. 1(ALPHANUMERIC)25...................... Valid Internet E-Mail Internet E-Mail address of
address. Customer contact person.
CUSTOMER__FAX..................... CUSTEFAX.............. 14(ALPHANUMERIC)20..................... Area code and Fax phone number of Customer
telephone number, contract person.
plus any extensions
(aaa)-nnn-nnnn xnnnn.
CUSTOMER__NAME.................... CUSTNAME.............. 1(ALPHANUMERIC)25...................... Free form text....... Name of Customer contract
person.
CUSTOMER__PHONE................... CUSTPHON.............. 14(ALPHANUMERIC)20..................... Area code and Telephone of Customer
telephone number, contact person.
plus any extensions
(aaa)-nnn-nnnn xnnnn.
DATA__ROWS........................ 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.
DATE__TIME__EFFECTIVE............. TIMEEFCT.............. 16(ALPHANUMERIC)16..................... Valid date and time Date and time a message or
in seconds service offer is in effect.
yyyy+mo+dd+hh
+mm+ss+tz.
DATE__TIME__POSTED................ TIMEPSTD.............. 16(ALPHANUMERIC)16..................... Valid date and time Date and time to seconds a
in seconds message or service offered
yyyy+mo+dd+hh was posted.
+mm+ss+tz.
DEAL__REF......................... DREF.................. 1(ALPHANUMERIC) 12..................... Unique value, The unique reference
Assigned by Customer. 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 DEAL__REF to
uniquely identify a
combination of requests
relating to a particular
deal.
DISCRETION__DESCRIPTION........... DISCDESC.............. 0(ALPHANUMERIC)1000.................... Free form text....... A detailed description of
the discretion being
reported.

[[Page 38945]]

ELEMENT__NAME..................... ELEMENT............... 1(ALPHANUMERIC)40...................... Valid Template Template element name as
element name. indicated in data
dictionary.
EMPLOYEE__NAME.................... EMPNAME............... 1(ALPHANUMERIC)25...................... Free form text....... Name of person who is
transferring from one
position to another.
ERROR__MESSAGE.................... ERROR................. 1(ALPHANUMERIC)250..................... Free form text....... Error message related to a
RECORD__STATUS or
REQUEST__STATUS.
FORMER__COMPANY................... FORMCO................ 1(ALPHANUMERIC)25...................... Free form text....... Former company of the person
who is transferring.
FORMER__DEPARTMENT................ FORMDEPT.............. 1(ALPHANUMERIC)25...................... Free form text....... Former department of the
person who is transferring.
FORMER__POSITION.................. FORMPOS............... 1(ALPHANUMERIC)25...................... Free form text....... Former position held by the
person who is transferring.
INTERFACE__TYPE................... 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.
LIST__ITEM........................ 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
SERVICE__INCREMENT,
TS__CLASS, TS__TYPE,
TS__PERIOD, NERC__
CURTAILMENT__PRIORITY,
OTHER__CURTAILMENT__
PRIORITY,
SERVICE__INCREMENT,
CATEGORY List of TEMPLATEs.
LIST__ITEM__ DESCRIPTION.......... ITEMDESC.............. 0(ALPHANUMERIC)100..................... Free form text....... A detailed description of
the LIST__ITEM.
LIST__NAME........................ LIST.................. 1(alphanumeric)25...................... LIST, SELLER, PATH, List of valid names for each
POR, POD, of the types of lists. The
SERVICE__INCREMENT, minimum set of lists
TS__CLASS, TS__TYPE, defined must be
TS__PERIOD, implemented.
TS__SUBCLASS,
ANCILLARY__SERVICE__
TYP E, CATEGORY,
TEMPLATE.
MESSAGE........................... MSG................... 1(ALPHANUMERIC)200.................... Free form text....... An informative text message.
NEGOTIATED__PRICE__FLAG........... NGPRIFLG.............. 1(ALPHANUMERIC)1....................... H, L, or blank....... Set to H if OFFER__PRICE is
higher than the currently
posted price; set to L if
OFFER__PRICE is lower than
the currently posted price.
NERC__CURTAILMENT__ PRIORITY...... NERCURT............... 1(NUMERIC)1............................ Integer 1-7.......... One of the NERC seven
curtailment priorities,
documented in LIST templat.
NEW__COMPANY...................... NEWCO................. 1(ALPHANUMERIC)25...................... Free form text....... New company of the person
who is transferring.
NEW__DATA......................... NEWDATA............... 1(ALPHANUMERIC)200..................... Any valid date For audit log, the new
element value. updated value of a Template
data element after update.
NEW__DEPARTMENT................... NEWDEPT............... 1(ALPHANUMERIC)25...................... Free form text....... New department of the person
who is transferring.
NEW__POSITION..................... NEWPOS................ 1(ALPHANUMERIC)25...................... Free form text....... New position held by the
person who is transferring.
OFFER__PRICE...................... OFFPR................. 1(NUMERIC)5 + ``.'' + 2(NUMERIC)2...... Positive number with The current offered price of
2 decimals. a Service in dollars and
cents. Used by the Seller
to indicate the offering
price.
OFFER__START__TIME................ OFFSTIME.............. 16(ALPHANUMERIC)16..................... Valid Date and Time Start time of the window
to seconds: during which a Customer may
yyy+mo+dd+hh+mmm+ request a discounted offer.
ss+tz.
OFFER__ STOP__TIME................ OFFSPTIME............. 16(ALPHANUMERIC)16..................... Valid Date and Time Stop time of the window
to seconds: during which a Customer may
yyyy+mo+dd+hh........ request a discounted offer.
+mm+ss+tz............ (Expiration time of an
offer).
OLD__DATA......................... OLDDATA............... 1(ALPHANUMERIC)200..................... Any valid data For audit log, the old value
element value. of a Template data element
prior to being updated.
This element is not
applicable in the audit log
for transaction events.

[[Page 38946]]

OPTIONAL__CODE.................... N/A................... 0(ALPHANUMERIC)25...................... Unique path name OPTIONAL__CODE--25 chars,
within region. 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 PATH__NAME.
OTHER__CURTAILMENT __PRIORITY..... 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.
OUTPUT__FORMAT.................... 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.
PATH__CODE........................ N/A................... 0(ALPHANUMERIC)12...................... Unique code for each Unique code within a Region
path as defined by for each path. Used by
primary provider. PATH__NAME.
PATH__NAME........................ 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 OPTION__CODE and
SPARE__CODE:
REGION__CODE--2 chars,
unique to OASIS System
PRIMARY__PROVIDER__CODE--4
chars, unique within Region
PATH__CODE--12 chars, unique
for Primary Provider
OPTIONAL__CODE--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
SPARE__CODE--3 chars.
POINT__ OF__DELIVERY.............. POD................... 1(ALPHANUMERIC)12...................... Unique value within Point of Delivery is one or
Primary Provider. 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.

[[Page 38947]]

POINT__OF __RECEIPT............... POR................... 1(ALPHANUMERIC)12...................... Unique value within Point of Receipt is one or
Primary Provider. 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.
POSTING__NAME..................... POSTNAME.............. 1(ALPHANUMERIC)25...................... Free form text....... Name of person who is
posting the information on
the OASIS.
POSTING__REF...................... 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.
PRICE__UNITS...................... UNITS................. 1(ALPHA)20............................. Free form text....... The units used for
CEILING__PRICE,
OFFER__PRICE, and
BID__PRICE.
Examples: $/MWhr, $/MWmonth
PRIMARY__ PROVIDER__COMMENTS...... PPROVCOM.............. 1(ALPHANUMERIC)80...................... Free form text....... Informative text. Usually
entered by the Primary
Provider through a back end
system.
PRIMARY__ PROVIDER__CODE.......... PROVIDER.............. 1(ALPHANUMERIC)4....................... Unique code.......... Unique code for each Primary
Provider. Used by
PATH__NAME and in URL.
Registered as part of URL
at www.tsin.com.
PRIMARY__ PROVIDER__DUNS.......... PPROV-................ 9(NUMERIC)9............................ Valid DUNS number.... Unique code for each
DUNS................ Primary. Provided by Dun
and Bradstreet.
REASSIGNED__ CAPACITY............. RASCAP................ 1(NUMERIC)12........................... Positive number, The amount of transfer
cannot exceed capability that was
previous assigned reassigned from one entity
capacity. to another.
REASSIGNED__ REF.................. REREF................. 1(ALPHANUMERIC)12...................... Unique value......... When customer makes a
purchase of a transmission
service that was posted for
resale and a new
ASSIGNMENT__REF number is
issued the previous
ASSIGNMENT__REF number now
becomes the
REASSIGNMENT__REF. 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.
REASSIGNED__START__TIME........... RESSTIME.............. 16(ALPHANUMERIC)16..................... Valid date and time Beginning date and time of
to seconds: the reassigned transmission
yyy+mo+dd+hh+tz service.
REASSIGNED__STOP__TIME............ RESSPIME.............. 16(ALPHANUMERIC)16..................... Valid date and time Date and time of the end of
to hour: the transmission service
yyyy+mo+dd+hh+tz that is reassigned to
another User.
RECORD__STATUS.................... REC-.................. 1(NUMERIC)3............................ Error number......... Record status indicating
STATUS.............. record was successful or
error code if unsuccessful.
200=Successful

[[Page 38948]]

REGION__CODE...................... N/A................... 1(ALPHANUMERIC)2....................... Unique within OASIS Defined for NERC regions,
System. 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.
REQUEST__REF...................... RREF.................. 1(ALPHANUMERIC)12...................... Unique value......... A reference uniquely
assigned by a Customer to a
request for service from a
Provider.
REQUEST__STATUS................... RSTATUS............... 1(NUMERIC)3............................ Error number......... Message status indicating
message was successful (if
all RECORD__STATUS show
success) or error code if
any RECORD__STATUS showed
unsuccessful.
200=Successful.
RESPONSE__TIME__LIMIT............. RESPTL................ 16(ALPHANUMERIC)16..................... Valid date and time Date and time to seconds by
to seconds: when a response must be
yyyy+mo+dd+hh received from a Customer.
+mm+ss+tz
RESPONSIBLE__PARTY__NAME.......... PARTNAME.............. 1(ALPHANUMERIC)25...................... Free form text....... The name of the person
responsible for granting
the discretion.
RETURN__TZ........................ TZ.................... 2(ALPHANUMERIC)2....................... AD, AS, PD, PS, ED, A time zone code, indicating
ES, MD, MS, CD, CS, the base time zone, and
UT. 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.
SALE__REF......................... SREF.................. 1(ALPHANUMERIC)12...................... Unique value......... Identifier which is set by
seller (including Primary
Provider) when posting a
service for sale.
SELLER__CODE...................... SELLER................ 1(ALPHANUMERIC)6....................... Unique value......... Organization name of Primary
Provider or Reseller.
SELLER__COMMENTS.................. SELCOM................ 1(ALPHANUMERIC)80...................... Free form text....... Informative text provided by
the Seller.
SELLER__DUNS...................... SELDUNS............... 9[NUMERIC]9............................ Valid DUNS number.... Unique Data Universal
Numbering System provided
by Dun and Bradstreet. Code
for a Primary Provider or
Seller.
SELLER__EMAIL..................... SELEMAIL.............. 5[ALPHANUMERIC]60...................... Valid network E-Mail address of Seller
reference. contact person.
SERVICE__INCREMENT................ SRVINCR............... 1[ALPHANUMERIC]8....................... Valid increments..... The transmission service
HOURLY increments provided. Five
Daily are pre-defined, while
Weekly additional increments can
Monthly be used if they are
Yearly registered on TSIN.COM and
[Registered] shown in the Provider's
LIST template.
SELLER__FAX....................... SELFAX................ 14[ALPHANUMERIC]20..................... Area code and The fax telephone number for
telephone number, contact person at Seller.
plus any extensions
Example: (aaa)-nnn-
nnnn-xnnnn.
SELLER__NAME...................... SELNAME............... 1[ALPHANUMERIC]25...................... Free form text....... The name of an individual
contact person at the
Seller.
SELLER__PHONE..................... SELPHONE.............. 14[ALPHANUMERIC]20..................... Area code and The telephone number of a
telephone number, contact person as a Seller.
plus any extensions
(aaa)-nnn-nnnn xnnnn.
SERVICE__DESCRIPTION.............. SVCDESC............... 1[ALPHANUMERIC]200..................... Free-form text....... Information regarding a
service.
SERVICE__NAME..................... SVCNAME............... 1[ALPHANUMERIC]25...................... Free-form text....... Name of service affected by
the discretionary action.
SERVICE__TYPE..................... 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.

[[Page 38949]]

SOURCE............................ SOURCE................ 0[ALPHANUMERIC]14...................... Valid area name...... The area in which the SOURCE
is located.
SPARE__CODE....................... N/A................... 0[ALPHANUMERIC]3....................... Defined by region.... Spare code to be used at a
later time. Used by
PATH__NAME.
STANDARDS__OF__ CONDUCT__ISSUE.... STDISSUE.............. 0[ALPHANUMERIC]200..................... Free-form text....... Issues that were in
violation of the FERC
Standards of Conduct.
START__TIME....................... STIME................. 16[ALPHANUMERIC]16..................... Valid Date and Time Start date and clock time of
to seconds: a service. When used as a
yyyy+mo+dd+hh query variable, it requires
+mm+ss+tz 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.
START__TIME__POSTED............... STIMEP................ 16[ALPHANUMERIC]16..................... Valid Date and Time Query parameter to indicate
to seconds: all the records are to be
yyyy+mo+dd+hh retrieved that were posted
+mm+ss+tz on or after this time.
START__TIME__QUEUED............... STIMEQ................ 16[ALPHANUMERIC]16..................... Valid Date and Time Start date and clock time of
to seconds: a service, used for
yyyy+mo+dd+hh requesting transactions
+mm+ss+tz queued after this time.
STATUS............................ STATUS................ 5(ALPHANUMERIC)25...................... Valid field (QUEUED, QUEUED=initial status
RECEIVED, STUDY, assigned by TSP on receipt
REBID, OFFER, of ``customer capacity
ACCEPTED, REFUSED, purchase request''.
CONFIRMED, RECEIVED=reassigned by TP to
WITHDRAWN, acknowledge QUEUED requests
DISPLACED, ANNULLED, and indicate the service
RETRACTED). 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
OFFER__PRICE is being
proposed.
REBID=assigned by TC to
indicate a new BID__PRICE
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,
SELLER__COMMENTS 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.

[[Page 38950]]

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.
STATUS__COMMENTS.................. STACOM................ 1(ALPHANUMERIC)80...................... Free form text....... Informative text.
STATUS__NOTIFICATION.............. STATNOT............... 1(ALPHANUMERIC)200..................... http://URL:portnumber/ The STATUS__NOTIFICATION
director y/cgi data element shall contain
script/query the protocol field
parameters or ``http:'', which designates
Mailto: . 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.
STOP__TIME........................ SPTIME................ 16(ALPHANUMERIC)16..................... Valid date and time Stop date and clock time.
yyyy+mo+dd+hh+mm+ When used as a query
ss+tz. 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 STOP__TIME.
STOP__TIME__POSTED................ STPTIMEP.............. 16(ALPHANUMERIC)16.................... Valid date and time Query parameter to indicate
to seconds: all the records are to be
yyyy+mo+dd+hh+mm+ retrieved that were posted
ss+tz. on or before this time.
STOP__TIME__QUEUED................ SPTIMEQ............... 16(ALPHANUMERIC)16.................... Valid date and time Stop date and clock time,
to seconds: used for requesting
yyyy+mo+dd+hh+mm+ transactions queued before
ss+tz. this time.
SUBJECT........................... SUBJ.................. 1(ALPHANUMERIC)80..................... Free form text....... Informative text used to
summarize a topic in a
message.
TARIFF__REFERENCE................. TARIFF................ 1(ALPHANUMERIC)150.................... Free form text. Name Tariffs approved by FERC.
and description of
Tariff.
TEMPLATE.......................... TEMPL................. 1(ALPHANUMERIC)20...................... Valid Name of The name of a logical
Template from collection of
Section 4.3 or from DATA__ELEMENTS in a User's
LIST Template. interaction with an OASIS
Node.
TIME__OF__ LAST__UPDATE........... TLUPDATE.............. 16(ALPHANUMERIC)16..................... Valid date and time Date and time to seconds
to seconds: that data was last updated.
yyyy+mo+dd+hh+mm+ May be used to search data
ss+tz. updated since a specific
point in time.
TIME__POSTED...................... TIMEPST............... 16(ALPHANUMERIC)16..................... Valid date and time Date and time a message is
to seconds: posted.
yyyy+mo+dd+hh+mm+
ss+tz.

[[Page 38951]]

TIME__QUEUED...................... TIMEQ................. 16(ALPHANUMERIC)16..................... Valid date and time Date and time that the
to seconds: request was queued.
yyyy+mo+dd+hh+mm+
ss+tz.
TIME__STAMP....................... TSTAMP................ 16(ALPHANUMERIC)16..................... Valid date and time Time data is created.
to seconds:
yyyy+mo+dd+hh+mm+
ss+tz.
TS__CLASS......................... TSCLASS............... 1(ALPHANUMERIC)20...................... Valid classes:....... The transmission service
FIRM classes provided. Three are
NON-FIRM predefined, while
TTC additional classes can be
(Registered) used if they are registered
on TSIN.COM and shown in
the Provider's LIST
template page.
TS__PERIOD........................ TSPER................. 1(ALPHANUMERIC)20...................... Valid periods:....... The transmission service
ON__PEAK periods provided. Three are
OFF__PEAK predefined, while
FULL__PERIOD additional periods can be
(Registered) used if they are registered
on TSIN.COM and shown in
the Provider's LIST
template.
TS__SUBCLASS...................... TSSUBC................ 1(ALPHANUMERIC)20...................... Free form............ The transmission service
subclasses provided. These
are free form.
TS__TYPE.......................... TSTYPE................ 1(ALPHANUMERIC)20...................... Valid periods:....... The transmission service
POINT__TO__P types provided. Two are
OINT predefined, while
NETWORK additional types can be
(Registered) used if they are registered
on TSIN.COM and shown in
the Provider's LIST
template.
TS__WINDOW........................ TSWIND................ 1(ALPHANUMERIC)20...................... Valid periods:....... The transmission service
FIXED windows provided. Two are
SLIDING predefined, while
(Registered) 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 Time zones:
indication whether Atlantic time=AD, AS.
daylight savings Eastern time=ED, ES.
time is to be used. Central time=CD, CS.
Mountain time=MD, MS.
Pacific time=PD, PS.
Universal time=UT.
VALID__FROM__TIME................. VALFTIME.............. 16(ALPHANUMERIC)16..................... Valid time and date Date and time after which
yyyy+mo+dd+hh+mm+ the message is valid.
ss+tz.
VALID__TO__TIME................... VALTTIME.............. 16(ALPHANUMERIC)16..................... Valid date and time Date and time before which
yyyy+mo+dd+hh+mm+ the message is valid.
ss+tz.
VERSION........................... VER................... 1(REAL NUMBER)6........................ RANGE OF 1.0 TO Specifies which version of
9999.9. the OASIS Standards and
Communication Protocol to
use when interpreting the
request.
--------------------------------------------------------------------------------------------------------------------------------------------------------

Note: This attachment will not appear in the Code of Federal
Regulations.

[[Page 38952]]

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

[[Page 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

[[Page 38954]]

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 dial-up 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.

[[Page 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

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 PRIMARY__PROVIDER__CODE.
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 fetch__http) 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

[[Page 38956]]

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 off-line 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

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

[[Page 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

http://(OASIS Node name)/OASIS/(PRIMARY__PROVIDER__CODE)
Where:
(OASIS Node name) is the World Wide Web URL address of the OASIS
Information Provider.
(PRIMARY__PROVIDER__CODE) is the 4 character acronym of the primary
provider.
PRIMARY__PROVIDER__CODEs 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/(PRIMARY__PROVIDER__CODE/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/(PRIMARY__PROVIDER__CODE)/ (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
PATH__NAME, 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

[[Page 38958]]

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-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.
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

[[Page 38959]]

contained in a User data file (i.e., ``uploading a file containing a
URL string), require appropriate software (e.g., ``fetch__http'')
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 OUTPUT__FORMAT Query Variable:
a. HTML: If the User requests the response to have the format of
``HTML'' (OUTPUT__FORMAT=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
(OUTPUT__FORMAT=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'' (OUTPUT__FORMAT=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
(OUTPUT__FORMAT=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''

[[Page 38960]]

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
OUTPUT__FORMAT
PRIMARY__PROVIDER__CODE
PRIMARY__PROVIDER__DUNS
RETURN__TZ
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:

TIME__STAMP
VERSION
TEMPLATE
OUTPUT__FORMAT
PRIMARY__PROVIDER__CODE
PRIMARY__PROVIDER__DUNS
RETURN__TZ
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.,
PATH__NAME1=abc&PATH__NAME2=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 ``* * *SELLER__CODE=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, ``* * *SELLER__CODE=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., TIME__OF__LAST__UPDATE), OASIS shall
return to the user all requested information whose associated data
element time value (e.g. TIME__OF__LAST__UPDATE) 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. START__TIME__QUEUED and
STOP__TIME__QUEUED) that represents the start and stop of a time
interval but is associated with one single template data element (e.g.
TIME__QUEUED) 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. START__TIME and STOP__TIME query
variables) that represents the start and stop of one time interval but
is associated with another pair of template data elements (e.g.
START__TIME and STOP__TIME 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
START__TIME query variable, and the STOP__TIME query variable selects
all information whose START__TIME data element value is earlier than
the STOP__TIME query variable. For example:

The transoffering template query string START__TIME
970101000000ES&STOP__TIME 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

[[Page 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.nq
TEMPLATE=aaaaaaaaaaq
OUTPUT__FORMAT=[DATA]q
PRIMARY__PROVIDER__CODE=aaaaq
PRIMARY__PROVIDER__DUNS=nnnnnnnnnq
RETURN__TZ=aaq
DATA__ROWS=nnnq
COLUMN__HEADERS=[Template data element names separated by commas]q
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 DATA__ROWS Data Element shall define
the total number of data records that follow in the message after the
COLUMN__HEADERS record.
The COLUMN__HEADERS 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 OUTPUT__FORMAT=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:

REQUEST__STATUS=nnnq
ERROR__MESSAGE=aaa...q
TIME__STAMP=yyyymmddhhmmsstzq
VERSION=nn.nq
TEMPLATE=aaaaaaaaaaq
OUTPUT__FORMAT=DATAq
PRIMARY__PROVIDER__CODE=aaaaq
PRIMARY__PROVIDER__DUNS=nnnnnnnnnq
RETURN__TZ=tzq
DATA__ROWS=nnnq
COLUMN__HEADERS=[Template data element names separated by commas]q
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 DATA__ROWS Data Element shall define
the total number of data records returned in the message following the
COLUMN__HEADERS header record.
The COLUMN__HEADERS 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 COLUMN__HEADERS 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

[[Page 38962]]

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 PRIMARY__PROVIDER__CODE 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 PRIMARY__PROVIDER__CODE 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
COLUMN__HEADERS record. The number of Data Records in the message is
defined by the DATA__ROWS 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
CONTINUATION__FLAG. 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 CONTINUATION__FLAG 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 COLUMN__HEADERs 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 RECORD__STATUS and
ERROR__MESSAGE Data Elements which are included in each data record
(row) of the Response.
If no error was encountered in an Input data record, the
RECORD__STATUS Data Element in the corresponding Response record shall
be returned with a value of 200 (success), and the ERROR__MESSAGE shall
be blank.
If any error is detected in processing an Input data
record, it shall be indicated by a RECORD__STATUS Data Element value
other than 200. The ERROR__MESSAGE 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 REQUEST__STATUS and
ERROR__MESSAGE header records (see section 4.2.7.3):
If no errors were encountered in processing the User's
Input data records, the REQUEST__STATUS shall be returned with the
value of 200 (success), and the ERROR__MESSAGE shall be blank.
If any errors were detected in the Template Input data
records, the REQUEST__STATUS value shall any value other than 200, and
the ERROR__MESSAGE 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 RECORD__STATUS and ERROR__MESSAGE. 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

[[Page 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 RETURN__TZ header Query Variable or an appropriate OASIS
specific default. OASIS shall interpret RETURN__TZ 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
RETURN__TZ=ES would return all time Data Elements in Eastern Standard
Time year-round. However, a RETURN__TZ=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):

[[Page 38964]]

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 BID__PRICE which is different
from the OFFER__PRICE 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 STATUS__NOTIFICATION 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 OFFER__PRICE equal to the
value of BID__PRICE 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 NEGOTIATED__PRICE__FLAG data element is
set when the Seller agrees to a BID__PRICE (by setting OFFER__PRICE
equal to BID__PRICE) that is different from the previously posted
price. It will show ``higher'' when OFFER__PRICE is higher than the
posted price, and ``lower'' when the OFFER__PRICE 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 OFFER__PRICE which is different from the BID__PRICE
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 BID__PRICE 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
OFFER__PRICE 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 OFFER__PRICE less than
that posted in the transoffering (ancoffering) Template, the
transoffering (ancoffering) Template must be updated to reflect the new
OFFER__PRICE.
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 OFFER__PRICE matched BID__PRICE (i.e., seller must
set OFFER__PRICE equal to BID__PRICE prior to or coincident with
setting STATUS to accepted).
j. OASIS shall accept a customer initiated change in STATUS to
CONFIRMED only when BID__PRICE matches OFFER__PRICE (i.e., customer
must set BID__PRICE equal to OFFER__PRICE 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 OFFER__PRICE is being
proposed
REBID=assigned by TC to indicate that a new BID__PRICE is being
proposed
ACCEPTED=assigned by TP to indicate service request at the designated
OFFER__PRICE 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,
SELLER__COMMENTS 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

[[Page 38965]]

[GRAPHIC] [TIFF OMITTED] TR20JY98.000

BILLING CODE 6717-01-C

[[Page 38966]]

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 STATUS__NOTIFICATION 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
STATUS__NOTIFICATION 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 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 STATUS__NOTIFICATION 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 STATUS__NOTIFICATION data
element with the value of ``http:/cgi-bin/status?
DEAL__REF=8&REQUEST__REF=173'', OASIS shall deliver an HTTP
notification message using the URL: http//oasistc.xyz.com:80/cgi-bin/
status? DEAL__REF=8&REQUEST__REF=173
If the STATUS__NOTIFICATION 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 STATUS__NOTIFICATION 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 RETURN__TZ 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 ASSIGNMENT__REF of 245 would be.

GET http://oasistc.xyz.com:80/cgi-bin/
status?DEAL__REF=8&REQUEST__REF=173 HTTP/1.0
Content-type: text/x-oasis-civ
Content-length:
REQUEST__STATUS=200
TIME__STAMP=
VERSION=1.2
TEMPLATE=transstatus
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=ABC
PRIMARY__PROVIDER__DUNS=123456789
RETURN__TZ=
DATA__ROWS=1
COLUMN__HEADERS=CONTINUATION__FLAG, ASSIGNMENT__REF, . . .
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.

[[Page 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 STATUS__NOTIFICATION 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 STATUS__NOTIFICATION 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 STATUS__NOTIFICATION 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 ASSIGNMENT__REF 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 RETURN__TZ in formulating the transstatus
response information.
4.2.11 Reference Identifiers
The TSIP shall assign a unique reference identifier,
ASSIGNMENT__REF, for each Customer request to purchase capacity or
services. The value of ASSIGNMENT__REF 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
ASSIGNMENT__REF number is assigned, but previous ASSIGNMENT__REF
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, POSTING__REF,
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 POSTING__REF 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 ASSIGNMENT__REF
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 REASSIGNED__REF, REASSIGNED__START__TIME,
REASSIGNED__STOP__TIME, and REASSIGNED__CAPACITY data elements.
Sellers may identify their service offerings received from
customers through the Seller supplied value specified for the SALE__REF
data element.
Customers may track their purchase requests through the Customer
supplied values specified for the DEAL__REF and REQUEST__REF data
elements. Customers may also use POSTING__REF and SALE__REF 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 ANC__SVC__REQ
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
ANC__SVC__LINK 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 PRIMARY__PROVIDER__CODE, SELLER__CODE, or
CUSTOMER__CODE, 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 ANC__SVC__TYPE specified within parenthesis.

and where xxx represents either:
__``FT'' to indicate that the Customer will determine ancillary
services at a future time, or

[[Page 38968]]

__``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 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
__``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.

[[Page 38969]]

------------------------------------------------------------------------
Process Area Process Name Template(s)
------------------------------------------------------------------------
4.3.2 Query/Response of Query/Response transoffering
Posted Services Being Transmission
Offered. Capacity Offerings.
Query/Response ancoffering
Ancillary Service
Offerings.
4.3.3 Query/Response of Query/Response transserv
Services Information. Transmission
Services.
Query/Response ancserv
Ancillary Services.
4.3.4 Query/Response of Query/Response schedule
Schedules and Curtailments. Transmission
Schedules.
Query/Response curtail
Curtailments.
4.3.5 Query/Response of Query/Response List list
Lists of Information. of Sellers, Paths,
PORs, PODs,
Capacity Types,
Ancillary Service
Types, Templates.

4.3.6 Query/Response of Query/Response Audit auditlog
Audit Log. Log.
4.3.7 Purchase Transmission Request Purchase of transrequest
Services. Transmission
Services (Input).
Query/Response transstatus
Status of
Transmission
Service Request.
Seller Approves transsell
Purchase (Input).
Customer Confirm/ transcust
Withdraw Purchase
of Transmission
Service (Input).
Alternate POD/POR... transalt
Seller Reassign transassign
Rights (Input).
4.3.8 Seller Posting of Seller Post transpost
Transmission Service. Transmission
Service for Sale
(Input).
Seller Modify transupdate
(Remove)
Transmission
Service for Sale
(Input).
4.3.9 Purchase of Ancillary Request Purchase of ancrequest
Service. Ancillary Service
(Input).
Query/Response ancstatus
Status of Ancillary
Service Request.
Seller Approves ancsell
Purchase of
Ancillary Service
(Input).
Customer Accept/ anccust
Withdraw Purchase
of Ancillary
Service (Input).
4.3.10 Seller Post Seller Post ancpost
Ancillary Service. Ancillary Service
(Input).
Seller Modify ancupdate
(Remove) Ancillary
Service for Sale
(Input).
4.3.11 Informal Messages... Post Want Ads messagepost
(Input).
Query/Response Want message
Ads.
Delete Want Ad messagedelete
(Input).
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. START__TIME and STOP__TIME is the requested time interval
for the Response to show all offerings which intersect that interval
(see Section 4.2.6.6.). TIME__OF__LAST__UPDATE 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, OFFER__START__TIME and OFFER__STOP__TIME indicate
the ``request time window'' within which a customer must request a
service in order to get the post OFFER__PRICE. START__TIME and
STOP__TIME indicate the time frame that the service is being offered
for.
The SERVICE__DESCRIPTION data element shall define any attributes
and/or special terms and conditions applicable to the offering that are
not listed under the standard SERVICE__DESCRIPTION associated with the
product definition supplied in the transserv or ancsery templates.
SERVICE__DESCRIPTION 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 POSTING__REF 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 SERVICE__INCREMENT data
element, namely, hourly, daily, weekly, monthly, or yearly.
Template: transoffering
1. Query
PATH__NAME*
SELLER__CODE*
SELLER__DUNS*

[[Page 38970]]

POINT__OF__RECEIPT*
POINT__OF__DELIVERY*
SERVICE__INCREMENT*
TS__CLASS*
TS__TYPE*
TS__PERIOD*
START__TIME (of transmission services)
STOP__TIME (of transmission services)
POSTING__REF
TIME__OF__LAST__UPDATE
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 SELLER__CODEs, PATH__NAMEs, PORs, PODs, Ts__xxx, and
the START__TIME/STOP__TIME specified in the query. The SALE__REF is a
value provided by the SELLER to identify the transmission service
product being sold. The ANC__SVC__REQ indicates all ancillary services
required for the specified transmission services. All Templates
elements are defined in the Data Element Dictionary.

TIME__OF__LAST__UPDATE
SELLER__CODE
SELLER__DUNS
PATH__NAME
POINT__OF__RECEIPT
POINT__OF__DELIVERY
INTERFACE__TYPE
OFFER__START__TIME
OFFER__STOP__TIME
START__TIME
STOP__TIME
CAPACITY
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__WINDOW
TS__SUBCLASS
ANC__SVC__REQ
SALE__REF
POSTING REF
CEILING PRICE
OFFER__PRICE
PRICE__UNITS
SERVICE__DESCRITION (if null, then look at transserv)
NERC__CURTAILMENT__PRIORITY
OTHER__CURTAIMENT__PRIORITY
SELLER__NAME
SELLER__PHONE
SELLER__FAX
SELLER__EMAIL
SELLER__COMMENTS
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
SELLER__CODE*
SELLER__DUNS*
CONTROL__AREA*
SERVICE__INCREMENT*
ANC__SERVICE__TYPE*
START__TIME
STOP__TIME
POSTING__REF
TIME__OF__LAST__UPDATE
2. Response
TIME__OF__LAST__UPDATE

[[Page 38971]]

SELLER__CODE
SELLER__DUNS
CONTROL__AREA
OFFER__START__TIME
OFFER__STOP__TIME
START__TIME
STOP__TIME
CAPACITY
SERVICE__INCREMENT
ANCILLARY__SERVICE__TYPE
SALE__REF
POSTING__REF
CEILING__PRICE
OFFER__PRICE
PRICE__UNITS
SERVICE__DESCRIPTION (if blank, then look at ancserv)
SELLER__NAME
SELLER__PHONE
SELLER__FAX
SELLER__EMAIL
SELLER__COMMENTS
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 SERVICE__INCREMENT,
TS__CLASS, TS__TYPE, TS__PERIOD, TS__SUBCLASS, TS__WINDOW,
NERC__CURTAIMENT__PRIORITY, and OTHER__CURTAIMENT__PRIORITY 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 PRICE__UNITS with this
Template.
Template: transserv
1. Query
TIME__OF__LAST__UPDATE
2. Response
TIME__OF__LAST__UPDATE
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__WINDOW
TS__SUBCLASS
CEILING__PRICE
PRICE__UNITS
SERVICE__DESCRIPTION
NERC__CURTAILMENT__PRIORITY
OTHER__CURTIMENT__PRIORITY
TARIFF__REFERENCE
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 PRICE__UNITS with this Template.
Template: ancserv
1. Query
TIME__OF__LAST__UPDATE
2. Response
TIME__OF__LAST__UPDATE
SERVICE__INCREMENT
ANC__SERVICE__TYPE
CEILING__PRICE
PRICE__UNITS
SERVICE__DESCRIPTION
TARIFF__REFERENCE

[[Page 38972]]

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 CAPACITY__SCHEDULED,
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
PATH__NAME*
SELLER__CODE*
SELLER__DUNS*
CUSTOMER__CODE*
CUSTOMER__DUNS*
POINT__OF__RECEIPT*
POINT__OF__DELIVERY*
SERVICE__INCREMENT*
TS__CLASS*
TS__TYPE*
TS__PERIOD*
START__TIME
STOP__TIME
TIME__OF__LAST__UPDATE
ASSIGNMENT__REF
2. Response
TIME__OF__LAST__UPDATE
SELLER__CODE
SELLER__DUNS
PATH__NAME
POINT__OF__RECEIPT
POINT__OF__DELIVERY
CUSTOMER__CODE
CUSTOMER__DUNS
AFFILIATE__FLAG
START__TIME (start time of schedule)
STOP__TIME (stop time of schedule)
CAPACITY (reserved)
CAPACITY__SCHEDULED (total of energy scheduled for this customer for
this reservation for this hour)
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__WINDOW
TS__SUBCLASS
NERC__CURTAILMENT__PRIORITY
OTHER__CURTAILMENT__PRIORITY
ASSIGNMENT__REF (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 CAPACITY__CURTAILED, CURTAILMENT__REASON and
CURTAILMENT__OPTIONS. 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
PATH__NAME*
SELLER__CODE*
SELLER__DUNS*
CUSTOMER__CODE*
CUSTOMER__DUNS*
POINT__OF__RECEIPT*
POINT__OF__DELIVERY*

[[Page 38973]]

SERVICE__INCREMENT*
TS__CLASS*
TS__TYPE*
TS__PERIOD*
START__TIME
STOP__TIME
TIME__OF__LAST__UPDATE
ASSIGNMENT__REF
2. Response
TIME__OF__LAST__UPDATE
SELLER__CODE
SELLER__DUNS
PATH__NAME
POINT__OF__RECEIPT
POINT__OF__DELIVERY
CUSTOMER__CODE
CUSTOMER__DUNS
AFFILIATE__FLAG
START__TIME (Start time of curtailment)
STOP__TIME (Stop time of curtailment)
CAPACITY (Capacity reserved)
CAPACITY__SCHEDULED
CAPACITY__CURTAILED
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__WINDOW
TS__SUBCLASS
NERC__CURTAILMENT__PRIORITY
OTHER__CURTAILMENT__PRIORITY
CURTAILMENT__REASON
CURTAILMENT__PROCEDURES
CURTAILMENT__OPTIONS
ASSIGNMENT__REF
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, SELLER__CODEs, PATHs, PORs, PODs,
SERVICE__INCREMENTs, TS__CLASSes, TS__TYPEs, TS__PERIODS,
NERC__CURTAILMENT__PRIORITY, OTHER__CURTAILMENT__PRIORITY,
ANCILLARY__SERVICE__TYPEs, CATEGORYs, and TEMPLATEs. These names may be
used to query information, post or request services.
Template: list
1. Query
LIST__NAME
TIME__OF__LAST__UPDATE
2. Response
TIME__OF__LAST__UPDATE
LIST__NAME
LIST__ITEM
LIST__ITEM__DESCRIPTION
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: TIME__STAMP, TEMPLATE,
ELEMENT__NAME, AND NEW__DATA. In this case the value of OLD__DATA is
not applicable.
Template: auditlog
1. Query
START__TIME (search against audit log)

[[Page 38974]]

STOP__TIME (search against audit log)
2. Response
ASSIGNMENT__REF OR POSTING__REF
TIME__STAMP
TEMPLATE
ELEMENT__NAME (for data elements whose values have changed)
OLD__DATA
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.
CUSTOMER__CODE and CUSTOMER__DUNS 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, BID__PRICE, START__TIME, AND
STOP__TIME.
For requesting transmission services which include multiple paths,
only the following fields may be redefined in a continuation record for
the transrequest Template. PATH__NAME. Supporting multiple paths is at
the discretion of the Provider.
The START__TIME and STOP__TIME indicate the requested period of
service.
When the request is received at the OASIS Node, the TSIP assigns a
unique ASSIGNMENT__REF 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
CONTINUATION__FLAG
SELLER__CODE (Primary or Reseller)
SELLER__DUNS
PATH__NAME
POINT__OF__RECEIPT
POINT__OF__DELIVERY
SOURCE
SINK
CAPACITY
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__SUBCLASS
STATUS__NOTIFICATION
START__TIME
STOP__TIME
BID__PRICE
PRECONFIRMED
ANC__SVC__LINK
POSTING__REF (Optionally set by Customer)
SALE__REF (Optionally set by Customer)
REQUEST__REF (Optionally set by Customer)
DEAL__REF (Optionally set by Customer)
CUSTOMER__COMMENTS
2. Response (acknowledgment)
RECORD__STATUS
CONTINUATION__FLAG
ASSIGNMENT__REF (assigned by TSIP)
SELLER__CODE
SELLER__DUNS
PATH__NAME
POINT__OF__RECEIPT

[[Page 38975]]

POINT__OF__DELIVERY
SOURCE
SINK
CAPACITY
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__SUBCLASS
STATUS__NOTIFICATION
START__TIME
STOP__TIME
BID__PRICE
PRECONFIRMED
ANC__SVC__LINK
POSTING__REF
SALE__REF
REQUEST__REF
DEAL__REF
CUSTOMER__COMMENTS
ERROR__MESSAGE
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: PATH__NAME, CAPACITY,
START__TIME, STOP__TIME, REASSIGNED__REF, REASSIGNED__CAPACITY,
REASSIGNED__START__TIME, and REASSIGNED__STOP__TIME.
The AFFILIATE__FLAG will be set by the TSIP to indicate whether or
not the Customer is an affiliate of the Primary Provider. The
NEGOTIATED__PRICE__FLAG will be set by the TSIP to indicate whether the
OFFER__PRICE is higher, lower, or the same as the BID__PRICE.
Template: transstatus
1. Query
SELLER__CODE*
SELLER__DUNS*
CUSTOMER__CODE*
CUSTOMER__DUNS*
PATH__NAME*
POINT__OF__RECEIPT*
POINT__OF__DELIVERY*
SERVICE__INCREMENT*
TS__CLASS*
TS__TYPE*
TS__PERIOD*
STATUS*
START__TIME (Beginning time of service)
STOP__TIME
START__TIME__QUEUED (Beginning time queue)
STOP__TIME__QUEUED
NEGOTIATED__PRICE__FLAG
ASSIGNMENT__REF
REASSIGNED__REF
SALE__REF
REQUEST__REF
DEAL__REF
TIME__OF__LAST__UPDATE
2. Response
CONTINUATION__FLAG
ASSIGNMENT__REF
SELLER__CODE
SELLER__DUNS
CUSTOMER__CODE
CUSTOMER__DUNS
AFFILIATE__FLAG (Set by TSIP)

[[Page 38976]]

PATH__NAME
POINT__OF__RECEIPT
POINT__OF__DELIVERY
SOURCE
SINK
CAPACITY (total reservation)
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__WINDOW
TS__SUBCLASS
NERC__CURTAILMENT__PRIORITY
OTHER__CURTAILMENT__PRIORITY
START__TIME
STOP__TIME
CEILING__PRICE
OFFER__PRICE
BID__PRICE
PRECONFIRMED
ANC__SVC__LINK
ANC__SVC__REQ
ALTERNATE__SERVICE__FLAG
POSTING__REF
SALE__REF
REQUEST__REF
DEAL__REF
NEGOTIATED__PRICE__FLAG (``L'' if Seller accepted Price is lower than
OFFER__PRICE in transoffering Template; ``H'' if higher; otherwise
blank)
STATUS=RECEIVED, QUEUED, STUDY, REBID, OFFER, ACCEPTED, REFUSED,
CONFIRMED, WITHDRAWN, DISPLACED, ANNULLED, RETRACTED
STATUS__NOTIFICATION
STATUS__COMMENTS
TIME__QUEUED
RESPONSE__TIME__LIMIT
TIME__OF__LAST__UPDATE
PRIMARY__PROVIDER__COMMENTS
SELLER__COMMENTS
CUSTOMER__COMMENTS
SELLER__NAME
SELLER__PHONE
SELLER__FAX
SELLER__EMAIL
CUSTOMER__NAME
CUSTOMER__PHONE
CUSTOMER__FAX
CUSTOMER__EMAIL
REASSIGNED__REF
REASSIGNED__CAPACITY (Capacity from each previous transaction)
REASSIGNED__START__TIME
REASSIGNED__STOP__TIME
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, STATUS__COMMENTS, SELLER__COMMENTS, REASSIGNED__REF,
NEGOTIATED__PRICE__FLAG, ANC__SRV__REQ, REASSIGNED__START__TIME,
REASSIGNED__STOP__TIME, and REASSIGNED__CAPACITY. If not preconfirmed,
then the Seller can also change OFFER__PRICE.
Only the following fields may be redefined in a continuation record
for the transsell Template: REASSIGNED__CAPACITY, OFFER__PRICE,
REASSIGNED__REF, REASSIGNED__START__TIME, and REASSIGNED__STOP__TIME.
SELLER__CODE and SELLER__DUNS shall be determined from the
registered connection used to input the request.
The Seller may accept a reservation only when the BID__PRICE and
the OFFER__PRICE are the same.
Template: transsell
1. Input
CONTINUATION__FLAG

[[Page 38977]]

ASSIGNMENT__REF (Required)
OFFER__PRICE
STATUS=RECEIVED, STUDY, OFFER, ACCEPTED, REFUSED, ANNULLED, RETRACTED,
DISPLACED
STATUS__COMMENTS
OTHER__CURTAILMENT__PROPERTY (optional)
ANC__SVC__REQ
NEGOTIATED__PRICE__FLAG
SELLER__COMMENTS
RESPONSE__TIME__LIMIT
REASSIGNED__REF
REASSIGNED__CAPACITY (Previous capacity to be reassigned)
REASSIGNED__START__TIME
REASSIGNED__STOP__TIME
2. Response
RECORD__STATUS
CONTINUATION__FLAG
ASSIGNMENT__REF
OFFER__PRICE
STATUS=RECEIVED, STUDY, OFFER, ACCEPTED, REFUSED, ANNULLED, RETRACTED,
DISPLACED
STATUS__COMMENTS
OTHER__CURTAILMENT__PRIORITY
ANC__SVC__REQ
NEGOTIATED__PRICE__FLAG
SELLER__COMMENTS
RESPONSE__TIME__LIMIT
REASSIGNED__REF
REASSIGNED__CAPACITY (Previous capacity to be reassigned)
REASSIGNED__START__TIME
REASSIGNED__STOP__TIME
ERROR__MESSAGE
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 BID__PRICE, STATUS, STATUS__COMMENTS, ANC__SVC__LINK, and
CUSTOMER__COMMENTS data elements can be modified in this Template.
CUSTOMER__CODE and CUSTOMER__DUNS shall be determined from the
registered connection used to input the request.
The Customer must change the BID__PRICE to be equal to the
OFFER__PRICE for each record before the STATUS can be set to CONFIRMED.
Template: transcust
1. Input
CONTINUATION__
ASSIGNMENT__REF (Required)
REQUEST__REF
DEAL__REF
BID__PRICE
STATUS=REBID, CONFIRMED, WITHDRAWN
STATUS__COMMENTS
ANC__SVC__LINK
STATUS__NOTIFICATION If left blank, then original URL from the
transrequest will be used
CUSTOMER__COMMENTS
2. Response
RECORD__STATUS
CONTINUATION__FLAG
ASSIGNMENT__REF
REQUEST__REF
DEAL__REF
BID__PRICE
STATUS=REBID, CONFIRMED, WITHDRAWN
STATUS__COMMENTS
ANC__SVC__LINK
STATUS__NOTIFICATION
CUSTOMER__COMMENTS
ERROR__MESSAGE

[[Page 38978]]

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 REASSIGNED__REF 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.
CUSTOMER__CODE and CUSTOMER__DUNS shall be determined from the
registered connection used to input the request.
REASSIGNED__REF contains the ASSIGNMENT__REF of the original,
confirmed reservation that is being designated to the alternate points
of delivery/receipt. The Template allows for only one REASSIGNED__REF
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 REASSIGNED__REF).
Demand profiles associated with the designation of alternate POD/
POR may be submitted by additional records designating ``Y'' for
CONTINUATION__FLAG, and specifying the CAPACITY, START__TIME, and
STOP__TIME data elements corresponding to the MW demand being requested
over each time interval associated with the reservation. The CAPACITY,
START__TIME, and STOP__TIME 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:

SELLER__CODE (value from SELLER__CODE in reservation designated by
REASSIGNED__REF)
SELLER__DUNS (value from SELLER__DUNS in reservation designated by
REASSIGNED__REF)
ALTERNATE__SERVICE__FLAG=YES
OFFER__PRICE=$0
BID__PRICE=$0
CEILING__PRICE=$0
TS__CLASS=Non-Firm (or whatever the Provider designates)
REASSIGNED__CAPACITY=MW capacity submitted in CAPACITY field of
Template
REASSIGNED__START__TIME=time submitted in START__TIME field of Template
REASSIGNED__STOP__TIME=time submitted in STOP__TIME field of Template
Template: transalt
1. Input
CONTINUATION__FLAG
PATH__NAME
POINT__OF__DELIVERY
SOURCE
SINK
PRECONFIRMED
CAPACITY (Must be less than or equal to original capacity reservation)
STATUS__NOTIFICATION
START__TIME (Valid only to hour and within the time of original
reservation)
STOP__TIME (Valid only to hour and within the time of original
reservation)
CUSTOMER__COMMENTS
2. Response (acknowledgment)
RECORD__STATUS
CONTINUATION__FLAG
ASSIGNMENT__REF (assigned by the TSIP)
SELLER__CODE (Primary)
SELLER__DUNS
PATH__NAME
POINT__OF__RECEIPT
POINT__OF__DELIVERY
SOURCE
SINK
PRECONFIRMED
ALTERNATE__SERVICE__FLAG (Defaulted to YES)
CAPACITY (Capacity requested)
STATUS__NOTIFICATION
START__TIME
STOP__TIME
REQUEST__REF
DEAL__REF
REASSIGNED__REF (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

[[Page 38979]]

confirmed transactions that have occurred off the OASIS. The TSIP shall
assign a unique ASSIGNMENT__REF in the response (acknowledgment) and
enter the status CONFIRMED as viewed in the transstatus Template.
SELLER__CODE and SELLER__DUNS 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, START__TIME, STOP__TIME,
REASSIGNED__REF, REASSIGNED__CAPACITY, REASSIGNED__START__TIME, and
REASSIGNED__STOP__TIME.
SELLER__CODE and SELLER__DUNS shall be determined form the
registered connection used to input the request.
Template: transassign
1. Input
CONTINUATION__FLAG
CUSTOMER__CODE
CUSTOMER__DUNS
PATH__NAME
POINT__OF__RECEIPT
POINT__OF__DELIVERY
SOURCE
SINK
CAPACITY
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__SUBCLASS
START__TIME
STOP__TIME
OFFER__PRICE
ANC__SVCX__LINK (optional: filled in if assignment is different than
original transmission reservation)
POSTING__NAME
REASSIGNED__REF
REASSIGNED__CAPACITY (Capacity being sold from each previous
assignment)
REASSIGNED__START__TIME
REASSIGNED__STOP__TIME
SELLER__COMMENTS
2. Response (acknowledgment)
RECORD__STATUS
CONTINUATION__FLAG
ASSIGNMENT__REF (assigned by TSIP)
CUSTOMER__CODE
CUSTOMER__DUNS
PATH__NAME
POINT__OF__RECEIPT
POINT__OF__DELIVERY
SOURCE
SINK
CAPACITY (Total capacity being reassigned)
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__SUBCLASS
START__TIME
STOP__TIME
OFFER__PRICE
ANC__SVC__LINK
POSTING__NAME
REASSIGNED__REF
REASSIGNED__CAPACITY (Capacity being sold from each previous
assignment)
REASSIGNED__START__TIME
REASSIGNED__STOP__TIME
SELLER__COMMENTS
ERROR__MESSAGE
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:

[[Page 38980]]

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.
SELLER__CODE and SELLER__DUNS shall be determined from the
registered connection used to input the request.
Template: transpost
1. Input
PATH__NAME
POINT__OF__RECEIPT
POINT__OF__DELIVERY
INTERFACE__TYPE
CAPACITY
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__WINDOW
TS__SUBCLASS
OTHER__CURTAILMENT__PRIORITY (optional)
ANC__SVC__REQ
START__TIME
STOP__TIME
OFFER__START__TIME
OFFER__STOP__TIME
SALE__REF
OFFER__PRICE
SERVICE__DESCRIPTION
SELLER__COMMENTS
2. Response (acknowledgement)
RECORD__STATUS
POSTING__REF (Assigned by TSIP)
PATH__NAME
POINT__OF__RECEIPT
POINT__OF__DELIVERY
INTERFACE__TYPE
CAPACITY
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__WINDOW
TS__SUBCLASS
OTHER__CURTAILMENT__PRIORITY
ANC__SVC__REQ
START__TIME
STOP__TIME
OFFER__START__TIME
OFFER__STOP__TIME
SALE__REF
OFFER__PRICE
SERVICE__DESCRIPTION
SELLER__COMMENTS
ERROR__MESSAGE
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.
SELLER__CODE and SELLER__DUNS shall be determined from the
registered connection used to input the request.
Template: transupdate
1. Input
POSTING__REF (Must be provided)
CAPACITY (only if modified)
START__TIME (only if modified)
STOP__TIME (only if modified)
OFFER__START__TIME (only if modified)
OFFER__STOP__TIME (only if modified)

[[Page 38981]]

ANC__SVC__REQ (only if modified)
SALE__REF (only if modified)
OFFER__PRICE (only if modified)
SERVICE__DESCRIPTION (only if modified)
SELLER__COMMENTS (only if modified)
2. Response (acknowledgment)
RECORD__STATUS
POSTING__REF
CAPACITY
START__TIME
STOP__TIME
OFFER__START__TIME
OFFER__STOP__TIME
ANC__SVC__REQ
SALE__REF
OFFER__PRICE
SERVICE__DESCRIPTION
SELLER__COMMENTS
ERROR__MESSAGE
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 STATUS__NOTIFICATION as for
transrequest. The reference Data Elements are optional.
CUSTOMER__CODE and CUSTOMER__DUNS shall be determined from the
registered connection used to input the request.
Template: ancrequest
1. Input
SELLER__CODE
SELLER__DUNS
CONTROL__AREA
CAPACITY
SERVICE__INCREMENT
ANC__SERVICE__TYPE
STATUS__NOTIFICATION
START__TIME
STOP__TIME
BID__PRICE
PRECONFIRMED
POSTING__REF (Optionally set by Customer)
SALE__REF (Optionally set by Customer)
REQUEST__REF (Optionally set by Customer)
DEAL__REF (Optionally set by Customer)
CUSTOMER__COMMENTS
2. Response (acknowledgement)
RECORD__STATUS
ASSIGNMENT__REF (assigned by TSIP)
SELLER__CODE
SELLER__DUNS
CONTROL__AREA
CAPACITY
SERVICE__INCRECMENT
ANC__SERVICE__TYPE
STATUS__NOTIFICATION
START__TIME
STOP__TIME
BID__PRICE
PRECONFIRMED
POSTING__REF
SALE__REF
REQUEST__REF
DEAL__REF
CUSTOMER__COMMENTS

[[Page 38982]]

ERROR__MESSAGE
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 AFFILIATE__FLAG 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
SELLER__CODE*
SELLER__DUNS*
CUSTOMER__CODE*
CUSTOMER__DUNS*
CONTROL__AREA
SERVICE__INCREMENT
ANC__SERVICE__TYPE
STATUS
START__TIME
STOP__TIME
START__TIME__QUEUED
STOP__TIME__QUEUED
ASSIGNMENT__REF
SALE__REF
REQUEST__REF
DEAL__REF
TIME__OF__LAST__UPDATE (only if TIME__OF__LAST__UPDATE is posted by
record)
2. Response
ASSIGNMENT__REF
SELLER__CODE
SELLER__DUNS
CUSTOMER__CODE
CUSTOMER__DUNS
AFFILIATE__FLAG (Set by TSIP)
CONTROL__AREA
CAPACITY
SERVICE__INCREMENT
ANC__SERVICE__TYPE
START__TIME
STOP__TIME
CEILING__PRICE
OFFER__PRICE
BID__PRICE
PRECONFIRMED
POSTING__REF
SALE__REF
REQUEST__REF
DEAL__REF
NEGOTIATED__PRICE__FLAG (``L if Seller accepted Price is lower than
OFFER__PRICE in ancoffering Template; ``H'' if higher; otherwise blank)
STATUS=QUEUED, RECEIVED, REBID, OFFER, ACCEPTED, REFUSED, CONFIRMED,
WITHDRAWN, ANNULLED, RETRACTED
STATUS__NOTIFICATION
STATUS__COMMENTS
TIME__QUEUED
RESPONSE__TIME__LIMIT
TIME__OF__LAST__UPDATE
PRIMARY__PROVIDER__COMMENTS
SELLER__COMMENTS
CUSTOMER__COMMENTS
SELLER__NAME
SELLER__PHONE
SELLER__FAX
SELLER__EMAIL
CUSTOMER__NAME
CUSTOMER__PHONE

[[Page 38983]]

CUSTOMER__FAX
CUSTOMER__EMAIL
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.
SELLER__CODE and SELLER__DUNS shall be determined from the
registered connection used to input the request.
Template: ancsell
1. Input
ASSIGNMENT__REF
OFFER__PRICE
STATUS=RECEIVED, OFFER, ACCEPTED, REFUSED
STATUS__COMMENTS
SELLER__COMMENTS
2. Response (acknowledgment)
RECORD__STATUS
ASSIGNMENT__REF
OFFER__PRICE
STATUS=RECEIVED, OFFER, ACCEPTED, REFUSED
STATUS__COMMENTS
NEGOTIATED__PRICE__FLAG
RESPONSE__TIME__LIMIT
SELLER__COMMENTS
ERROR__MESSAGE
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 BID__PRICE to be equal to the
OFFER__PRICE before the STATUS can be set to CONFIRMED.
CUSTOMER__CODE and CUSTOMER__DUNS shall be determined from the
registered connection used to input the request.
Template: anccust
1. Input
ASSIGNMENT__REF (Required)
REQUEST__REF
DEAL__REF
BID__PRICE
STATUS=REBID, CONFIRMED, WITHDRAWN
STATUS__COMMENTS
STATUS__NOTIFICATION (If left blank, then the original URL from the
ancrequest will be used)
CUSTOMER__COMMENTS
2. Response (Acknowledgment)
RECORD__STATUS
ASSIGNMENT__REF
REQUEST__REF
DEAL__REF
BID__PRICE
STATUS=REBID, CONFIRMED, WITHDRAWN
STATUS__COMMENTS
STATUS__NOTIFICATION
CUSTOMER__COMMENTS
ERROR__MESSAGE
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.
SELLER__CODE and SELLER__DUNS shall be determined from the
registered connection used to input the request.
Template: ancpost
1. Input
CONTROL__AREA

[[Page 38984]]

SERVICE__DESCRIPTION
CAPACITY
SERVICE__INCREMENT
ANC__SERVICE__TYPE
START__TIME
STOP__TIME
OFFER__START__TIME
OFFER__STOP__TIME
SALE__REF
OFFER__PRICE
SELLER__COMMENTS
2. Response (acknowledgment)
RECORD__STATUS
POSTING__REF (Assigned by TSIP)
CONTROL__AREA
SERVICE__DESCRIPTION
CAPACITY
SERVICE__INCREMENT
ANC__SERVICE__TYPE
START__TIME
STOP__TIME
OFFER__START__TIME
OFFER__STOP__TIME
SALE__REF
OFFER__PRICE
SELLER__COMMENTS
ERROR__MESSAGE
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.
SELLER__CODE and SELLER__DUNS shall be determined from the
registered connection used to input the request.
Template: ancupdate
1. Input
POSTING__REF (Required)
CAPACITY (only if modified)
SERVICE__DESCRIPTION (only if modified)
START__TIME (only if modified)
STOP__TIME (only if modified)
OFFER__START__TIME (only if modified)
OFFER__STOP__TIME (only if modified)
SALE__REF (only if modified)
OFFER__PRICE (only if modified)
SELLER__COMMENTS (only if modified)
2. Response (acknowledgment)
RECORD__STATUS
POSTING__REF
CAPACITY
SERVICE__DESCRIPTION
START__TIME
STOP__TIME
OFFER__START__TIME
OFFER__STOP__TIME
SALE__REF
OFFER__PRICE
SELLER__COMMENTS
ERROR__MESSAGE
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.

[[Page 38985]]

CATEGORY__CODE and CUSTOMER__DUNS shall be determined from the
registered connection used to input the request.
Template: messagepost
1. Input
SUBJECT
CATEGORY
VALID__FROM__TIME
VALID__TO__TIME
MESSAGE (must be specified)
2. Response (acknowledgment)
RECORD__STATUS
POSTING__REF (assigned by information provider)
SUBJECT
CATEGORY
VALID__FROM__TIME
VALID__TO__TIME
MESSAGE
ERROR__MESSAGE
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
CUSTOMER__CODE
CUSTOMER__DUNS
POSTING__REF
CATEGORY
VALID__FROM__TIME
VALID__TO__TIME
TIME__POSTED
2. Response
CUSTOMER__CODE
CUSTOMER__DUNS
POSTING__REF
SUBJECT
CATEGORY
VALID__FROM__TIME
VALID__TO__TIME
TIME__POSTED
CUSTOMER__NAME
CUSTOMER__PHONE
CUSTOMER__FAX
CUSTOMER__EMAIL
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. POSTING__REF
number is used to determine which message.
CUSTOMER__CODE AND CUSTOMER__DUNS shall be determined from the
registered connection used to input the request.
Template: messagedelete
1. Input
POSTING__REF
2. Response (acknowledgment)
RECORD__STATUS
POSTING__REF
ERROR__MESSAGE
4.3.11.4 Personnel Transfers (personnel)
Template: personnel
1. Query
TIME__OF__LAST__UPDATE

[[Page 38986]]

START__TIME__POSTED
STOP__TIME__POSTED
2. Response
POSTING__NAME
EMPLOYEE__NAME
FORMER__POSITION
FORMER__COMPANY
FORMER__DEPARTMENT
NEW__POSITION
NEW__COMPANY
NEW__DEPARTMENT
DATE__TIME__EFFECTIVE
DATE__TIME__POSTED
TIME__OF__LAST__UPDATE
4.3.11.5 Discretion (discretion)
Template: discretion
1. Query
START__TIME__POSTED
STOP__TIME__POSTED
START__TIME
STOP__TIME
SERVICE__TYPE
SERVICE__NAME
TIME__OF__LAST__UPDATE
2. Response
POSTING__NAME
RESPONSIBLE__PARTY__NAME (name of person granting discretion)
SERVICE__TYPE (ancillary or transmission)
SERVICE__NAME (make consistent with offering Templates)
TARIFF__REFERENCE
START__TIME
STOP__TIME
DISCRETION__DESCRIPTION
TIME__POSTED
TIME__OF__LAST__UPDATE
4.3.11.6 Standards of Conduct (stdconduct)
Template: stdconduct
1. Query
START__TIME__POSTED
STOP__TIME__POSTED
TIME__OF__LAST__UPDATE
2. Response
POSTING__NAME
RESPONSIBLE__PARTY__NAME
STANDARDS__OF__CONDUCT__ISSUES
TIME__POSTED
TIME__OF__LAST__UPDATE

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 PATH__NAME ``W/AAAA/PATH__ABC//'' for April 10, 1996
from 8 a.m. to 3 p.m. (Note that the PATH__NAME consists of a
REGION__CODE, PRIMARY__PROVIDER__CODE, PATH__CODE, and an
OPTIONAL__CODE, 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)

[[Page 38987]]

TIME__STAMP=19960409113526PD
VERSION=1.2
TEMPLATE=transoffering
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AAAA
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=14
COLUMN__HEADERS= TIME__OF__LAST__UPDATE, SELLER__CODE, SELLER__DUNS,
PATH__NAME, POINT__OF__RECEIPT, POINT__OF__DELIVERY, INTERFACE__TYPE,
OFFER__START__TIME, OFFER__STOP__TIME, START__TIME,STOP__TIME,
CAPACITY, SERVICE__INCREMENT, TS__CLASS,TS__TYPE, TS__PERIOD,
TS__SUBCLASS, SALE__REF, POSTING__REF, CEILING__PRICE, OFFER__PRICE,
PRICE__UNITS, SERVICE__DESCRIPTION, SELLER__NAME, SELLER__PHONE,
SELLER__FAX, SELLER__EMAIL, SELLER__COMMENTS
19960409030000PD, WXYZ, 987654321, W/AAA/ABC//,N/A,N/A,E,
19960402080000PD, 19960410080000PD,
19960410080000PD,19960410090000PD,300, HOURLY, FIRM, POINT__TO__POINT,
OFF__PEAK, 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, POINT__TO__POINT, OFF__PEAK, 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, POINT__TO__POINT, OFF__PEAK, 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, POINT__TO__POINT, OFF__PEAK, 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,
POINT__TO__POINT, OFF__PEAK, 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, POINT__TO__POINT, OFF__PEAK, 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,
POINT__TO__POINT, OFF__PEAK, 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,
POINT__TO__POINT, OFF__PEAK, 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, POINT__TO__POINT,
OFF__PEAK, 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,
POINT__TO__POINT, OFF__PEAK, 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 fetch__http 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)
$ fetch__http 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
TIME__STAMP=1996041014702PD

[[Page 38988]]

VERSION=1.2
TEMPLATE=Schedule
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AAAA
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=5
COLUMN__HEADERS=TIME__OF__LAST__UPDATE, SELLER__CODE, SELLER__DUNS,
PATH__NAME, POINT__OF__RECEIPT, POINT__OF__DELIVERY, CUSTOMER__CODE,
CUSTOMER__DUNS, AFFILIATE__FLAG, START__TIME, STOP__TIME, CAPACITY,
CAPACITY__SCHEDULED, SERVICE__INCREMENT, TS__CLASS, TS__TYPE,
TS__PERIOD, TS__SUBCLASS, ASSIGNMENT__REF
19960409030000pd. wxyz, 0987654321,W/AAA/ABC//, BBB,CCC,
WXYZAA,0987654322,Y, 19960410100000PD, 19960410110000PD,300,300,
HOURLY, FIRM, POINT__TO__POINT, OFF__PEAK, N/A 856743
. . .
. . .
19960409030000pd, wxyz, 0987654321,W/AAA/ABC//,BBB,CCC, WXYZAA,
0987654322,Y, 19960410130000PD,19960410140000PD,300,300, HOURLY, FIRM,
POINT__TO__POINT, OFF__PEAK, N/A. 856743
19960409030000pd, wxyz, 0987654321,W/AAA/ABC//,BBB, CCC,WXYZAA,
0987654322,Y, 19960410140000PD, 19960410150000PD,
303,300.HOURLY,FIRM,POINT__TO__POINT,OFF__PEAK,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 FETCH__HTTP program to send
a file to the OASIS node of the Primary Provider.
1. Input
VERSION=1.2
TEMPLATE=transpost
OUTPUT__FORMAT=DATE
PRIMARY__PROVIDER__CODE=AAAA
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=1
COLUMN__HEADERS=PATH__NAME, POINT__OF__RECEIPT, POINT__OF__DELIVERY,
INTERFACE__TYPE, CAPACITY, SERVICE__INCREMENT, TS__CLASS, TS__TYPE,
TS__PERIOD, TS__SUBCLASS, START__TIME, STOP__TIME, OFFER__START__TIME,
OFFER__STOP__TIME, SALE__REF, OFFER__PRICE, SERVICE__DESCRIPTION,
SELLER__COMMENTPF
WXYZ,987654321, W/AAA/ABC//, N/A,N/A,E,150, HOURLY, FIRM,
POINT__TO__POINT, OFF__PEAK, N/A..19960402080000PD, 19960410080000PD,
19960410080000PD, 19960410150000PD, A123,.90.,N/A,````As Joe said, ``It
is a good buy''''''
FETCH__HTTP Command to spend posting
$fetch__http http://(OSASIS Node name)/OASIS/abcd/data/transrequest -
fc:/OASIS/abcd/upload/post.txt
2. Response Data
REQUEST-STATUS=200 (Successful)
TIME__STAMP=19960409113526PD
VERSION-1.2
TEMPLATE=Transport
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AAAA
PRIMARY__PROVIDER__DUNS=1234456789
DATA__ROWS=1
COLUMN__HEADERS=RECORD__STATUS, PATH__NAME, POINT__OF__RECEIPT,
POINT__OR__DELIVERY, INTERFACE__TYPE, CAPACITY, SERVICE__INCREMENT,
TS__CLASS, TS__TYPE, TS__PERIOD, TS__SUBCLASS, START__TIME, STOP__TIME,
OFFER__START__TIME, OFFER__STOP__TIME, SALE__REF, OFFER__PRICE,
SERVICE__DESCRIPTION, SELLER__COMMENTS, ERROR__MESSAGE
200,WXYZ, 987654321, W/AAA/ABC//,N/A,NA,E,150, HOURLY, FIRM,
POINT__TO__POINT, OFF__PEAK, 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
CUSTOMER__CODE=BestE
CAPACITY=150
TS__CLASS=``FIRM''

[[Page 38989]]

START TIME=``1996050708000000PD''
STOP__TIME=``1996050717000000PD''
BID__PRICE=``$1.00''
The Information Provider assigns ASSIGNMENT__REF = 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
ASSIGNMENT__REF=5001 when the request for purchase is made and is shown
in the acknowledgment.

TEMPLATE=``transpost''
SELLER__CODE=``BestE''
CAPACITY=100
TS__CLASS=``NON-FIRM''
START__TIME=``1996050708000000PD''
STOP__TIME=``1996050721000000PD''
SALE__REF=``BEST100''
OFFER__PRICE=.90
SELLER__COMMENTS-``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''
CUSTOMER__CODE=``Whisle''
SELLER__CODE=``BestE''
CAPACITY__=100
TS__CLASS=``NON-FIRM''
START__TIME=``1996050708000000PD''
STOP__TIME=``1996050721000000PD''
SALE__REF=``BEST100''
DEAL__REF=``WPC100''
BID__PRICE=.90
CUSTOMER__COMMENTS=``Only need service until 6 p.m.''
The Information Provider provides the ASSIGNMENT__REF=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''
CUSTOMER__CODE=``Whisle''
SELLER__CODE=``BestE''
ASSIGNMENT__REF=5002
STATUS=``Accepted''
REASSIGNED__REFI=5000
REASSIGNED__CAPACITY1=100
REASSIGNED__START__TIME1=``199605070800PD''
REASSIGNED__STOP__TIME1=``199605071700PD''
REASSIGNED__REF2=5001
REASSIGNED__CAPACITY2=100
REASSIGNED__START__TIME2=``199605071700PD''
REASSIGNED__STOP__TIME2=``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 ASSIGNMENT__REF by the OASIS
node.
Only the following fields may be redefined in a continuation record
for the transrequest Template: CAPACITY, START__TIME, STOP__TIME.
Specification of any values corresponding to COLUMN__HEADERs other than
CAPACITY, START__TIME, and STOP__TIME will be ignored, however commas
must be included to properly align the CAPACITY, START__TIME and
STOP__TIME fields.
Input:
VERSION=1.2
TEMPLATE=transrequest

[[Page 38990]]

OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AEP
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=7
COLUMN__HEADERS=CONTINUATION__FLAG, SELLER__CODE, SELLER__DUNS,
PATH__NAME, POINT__OF__RECEIPT, POINT__OF__DELIVERY, SOURCE, SINK,
CAPACITY, SERVICE__INCREMENT, TS__CLASS, TS__TYPE, TS__PERIOD,
TS__SUBCLASS, STATUS__NOTIFICATION, START__TIME, STOP__TIME,
BID__PRICE, PRECONFIRMED, ANC__SVC__LINK, POSTING__REF, SALE__REF,
REQUEST__REF, DEAL__REF, CUSTOMER__COMMENTS
N. AEP, 123456789, ABC/XY, CE, MECS...35, DAILY, FIRM,
POINT__TO__POINT, OFF__PEAK, 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,
POINT__TO__POINT, OFF__PEAK, 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,
POINT__TO__POINT, OFF__PEAK, 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:
REQUEST__STATUS=200
TIME__STAMP=19970422160523ES
TEMPLATE=transrequest
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AEP
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=7
COLUMN__HEADERS=RECORD__STATUS, CONTINUATION__FLAG, SELLER__CODE,
SELLER__DUNS, PATH__NAME, POINT__OF__RECEIPT, POINT__OF__DELIVERY,
SOURCE, SINK, CAPACITY, SERVICE__INCREMENT, TS__TYPE, TS__PERIOD,
TS__SUBLCASS, STATUS__NOTIFICATION, START__TIME, STOP__TIME,
BID__PRICE, PRECONFIRMED, ANC__SVC__LINK, POSTING__REF, SALE__REF,
REQUEST__REF, DEAL__REF, CUSTOMER__COMMENTS, ERROR__MESSAGE
200, N, AEP, 123456789, ABC/XY, CE, MECS,,,35, DAILY, FIRM,
POINT__TO__POINT, OFF__PEAK, 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,
POINT__TO__POINT, OFF__PEAK, 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,
POINT__TO__POINT, OFF__PEAK, 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 ASSIGNMENT__REF=7019, and Hourly Non-Firm in
amount of 10 MW from 08:00 to 20:00 on 4/23 under ASSIGNMENT__REF=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
(ASSIGNMENT__REF=7880) with the balance taken up by the Firm
reservation (ASSIGNMENT__REF=7019).
The only fields allowed in ``continuation'' records for transsell
Template are REASSIGNED__REF, REASSIGNED__CAPACITY,
REASSIGNED__START__TIME, and REASSIGNED__STOP__TIME. Price may not be
negotiated for each ``segment'' in a capacity profile.
Input:
VERSION=1.2
TEMPLATE=transsell
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AEP
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=3
COLUMN__HEADERS=CONTINUATION__FLAG, ASSIGNMENT__REF, OFFER__PRICE,
STATUS, STATUS__COMMENTS, ANC__SVC__LINK, SELLER__COMMENTS,
REASSIGNED__REF REASSIGNED__CAPACITY, REAS

[[Page 38991]]

SIGNED__START__TIME, REASSIGNED__STOP__TIME 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
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AEP
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=3
COLUMN__HEADERS=RECORD__STATUS, CONTINUATION__FLAG, ASSIGNMENT__REF,
OFFER__PRICE, STATUS, STATUS__COMMENTS, ANC__SVC__LINK,
SELLER__COMMENTS, REASSIGNED__REF, REASSIGNED__CAPACITY,
REASSIGNED__START__TIME, REASSIGNED__STOP__TIME, ERROR__MESSAGES 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 ``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 ASSIGNMENT__REF=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, START__TIME, STOP__TIME,
REASSIGNED__REF, REASSIGNED__CAPACITY, REASSIGNED__START__TIME, and
REASSIGNED__STOP__TIME.
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 CUSTOMER__NAME and SELLER__NAME were used to convey user
names for subsequent resolution of contact information from user
registration.
Input:
VERSION=1.2
TEMPLATE=transassign
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AEP
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=2
COLUMN__HEADERS=CONTINUATION__FLAG, CUSTOMER__CODE, CUSTOMER__DUNS,
PATH__NAME, POINT__OF__RECEIPT, POINT__OF__DELIVERY, SOURCE, SINK,
CAPACITY, SERVICE__INCREMENT, TS__CLASS, TS__TYPE, TS__PERIOD,
TS__SUBCLASS, START__TIME, STOP__TIME, OFFER__PRICE, SALE__REF,
POSTING__NAME, REASSIGNED__REF, REASSIGNED__CAPACITY,
REASSIGNED__START__TIME, REASSIGNED__STOP__TIME,
SELLER__COMMENTS
N, Resler, 456123789, Cust, 987654321, , CE, VP, , , 10, HOURLY, NON-
FIRM, POINT__TO__POINT, OFF__PEAK, 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:
REQUEST__STATUS=200
TIME__STAMP=19970422144520ES
VERSION=1.2
TEMPLATE=transassign
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AEP
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=2
COLUMN__HEADERS=RECORD__STATUS, CONTINUATION__FLAG, ASSIGNMENT__REF,
SELLER__CODE, SELLER__DUNS, CUSTOMER__CODE, CUSTOMER__DUNS,
AFFILIATE__FLAG, PATH__NAME, POINT__OF__RECEIPT, POINT__OF__DELIVERY,
SOURCE, SINK, CAPACITY, SERVICE__INCREMENT, TS__CLASS, TS__TYPE,
TS__PERIOD, TS__SUBCLASS, START__TIME, STOP__TIME, OFFER__PRICE,
SELLER__NAME, CUSTOMER__NAME, TIME__QUEUED, SALE__REF, REASSIGNED__REF,
REASSIGNED__CAPACITY, REASSIGNED__START__TIME, REASSIGNED__STOP__TIME,
SELLER__COMMENTS, ERROR__MESSAGE
200, N, 8207, Rseler, 456123789, Cust, 987654321, N, , CE, VP, , , 10,
HOURLY, FIRM, POINT__TO__POINT, OFF__PEAK, N/A 19970423000000ES,
19970423060000ES, 2.00, Joe Smith, Jane Doe, 19970422121354ES, , 7019,
10, 19970423000000ES, 19970423060000ES, Seller comments go
here,

[[Page 38992]]

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, START__TIME, STOP__TIME, REASSIGNED__REF,
REASSIGNED__CAPACITY, REASSIGNED__START__TIME, and
REASSIGNED__STOP__TIME (price fields are debatable).
Input:

Response:
REQUEST__STATUS=200
TIME__STAMP=19970423040523ES
TEMPLATE-transstatus
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AEP
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=11
COLUMN__HEADERS=CONTINUATION__FLAG, ASSIGNMENT__REF, SELLER__CODE,
SELLER__DUNS, CUSTOMER__CODE, CUSTOMER__DUNS, AFFILIATE__FLAG,
PATH__NAME, POINT__OF__RECEIPT, POINT__OF__DELIVERY, SOURCE, SINK,
CAPACITY, SERVICE__INCREMENT, TS__CLASS, TS__TYPE, TS__PERIOD,
TS__SUBCLASS, START__TIME, STOP__TIME, CEILING__PRICE, OFFER__PRICE,
BID__PRICE, PRECONFIRMED, ANC__SVC__LINK, ALTERNATE__SERVICE__FLAG,
POSTING__REF, SALE__REF, REQUEST__REF, DEAL__REF,
NEGOTIATED__PRICE__FLAG, STATUS, STATUS__COMMENTS, TIME__QUEUED,
TIME__OF__LAST__UPDATE, PRIMARY__PROVIDER__COMMENTS, SELLER__COMMENTS,
CUSTOMER__COMMENTS, SELLER__NAME, SELLER__PHONE, SELLER__FAX,
SELLER__EMAIL, CUSOMTER__NAME, CUSTOMER__PHONE, CUSTOMER__FAX,
CUSTOMER__EMAIL, REASSIGNED__REF, REASSIGNED,__CAPACITY,
REASSIGNED__START__TIME, REASSIGNED__STOP__TIME5
N, 8207, Rseler, 456123789, A Cust, 987654321, N, CE, VP, , , 10,
HOURLY, FIRM, POINT__TO__POINT, OFF__PEAK, 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,
[email protected], 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, POINT__TO__POINT, OFF__PEAK, 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, [email protected], 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, POINT__TO__POINT; OFF__PEAK, 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,
[email protected], 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, POINT__TO__POINT, OFF__PEAK, N/A 19970424040000ES,
19970424160000ES, 2.00, 2.50, 6.20, N, , , , , , CONFIRMED, ,
19970422160523ES, , Bid price refused, Negotiated OFFER__PRICE
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 OFFER__PRICE 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 OFFER__PRICE to the BID__PRICE.

[[Page 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 OFFER__PRICE officially
becomes the terms of the reservation.
4.4.6.2 Negotiations without Preconfirmation
e. The Customer submits a transmission reservation request with the
BID__PRICE 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 BID__PRICE is too low, sets the
OFFER__PRICE to the price he wants, and sets the STATUS to OFFER via
the transsell Template.
d. The Customer agrees to the OFFER__PRICE, sets the BID__PRICE
equal to the OFFER__PRICE, and sets the STATUS to CONFIRMED via the
transcust Template.
The OFFER__PRICE 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
BID__PRICE 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 STATUS via the transsell
Template to one of the following: RECEIVED, STUDY, ACCEPTED, OFFER, or
REFUSED.
c. The Seller determines that the BID__PRICE is too low, sets the
OFFER__PRICE to the desired value, and sets the STATUS to OFFER via the
transsell Template.
d. The Customer responds to the new OFFER__PRICE with an updated
BID__PRICE and sets the STATUS to REBID for re-evaluation by the
Seller.
e. The Seller determines that the BID__PRICE now is acceptable and
sets the STATUS to ACCEPTED via the transsell Template. The transition
to ACCEPTED state requires the OFFER__PRICE to be set to the
BID__PRICE: accepting a reservation with an OFFER__PRICE different from
BID__PRICE would require the STATUS be set to OFFER rather than
ACCEPTED (see item c).
f. The Customer agrees to the OFFER__PRICE and sets the STATUS to
CONFIRM via the transcust Template.
g. The OFFER__PRICE 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
BID__PRICE 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 BID__PRICE is too low, sets
OFFER__PRICE to his desired value, and sets STATUS to OFFER via the
transsell Template.
d. The Customer responds to OFFER__PRICE with updated BID__PRICE
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
BID__PRICE 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 BID__PRICE is too low, sets the
OFFER__PRICE to his desired value, and sets the STATUS to OFFER via the
transsell Template.
d. The Customer responds to the OFFER__PRICE with an updated
BID__PRICE and sets the STATUS to REBID for re-evaluation by Seller.
e. The Seller determines that the BID__PRICE is still too low, sets
the OFFER__PRICE 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

5.1 Security

[[Page 38994]]

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).
[GRAPHIC] [TIFF OMITTED] TR20JY98.004

A Provider account shall be considered to be down, and downtime
shall be accumlated, upon occurrence of any of the following:

[[Page 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

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.

[[Page 38996]]

Appendix A--Data Element Dictionary

Version 1.2

May 27, 1998

--------------------------------------------------------------------------------------------------------------------------------------------------------
Field format: minimum characters (type
Data dictionary element name Alias of ASCII) maximum characters Restricted values Definition of data element
--------------------------------------------------------------------------------------------------------------------------------------------------------
AFFILIATE__FLAG................... AFFLAG............... 1(ALPHANUMERIC)3...................... Valid Values Set to YES if customer is
YES an affiliate of the
NO provider.
ANC__SERVICE__TYPE................ 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)...
ANC__SVC__LINK.................... ANCSVCLINK........... 1(ALPHANUMERIC)300.................... Formatted string as The method for linking
follows.. ancillary services to a
SC:(AA); RV: (AA); RF: transmission service
(AA[:xxx[:yyy[:nnn]]]); request. The provider and
EL: capacity of each ancillary
(AA[:xxx[:yyy[:nnn]]]); service is identified
SP: using the formated string:
(AA[:xxx[:yyy[:nnn]]]); SC:(AA); RV:(AA);
SU...................... RF:AA[:xxx[:yyy[:nnn]]]);
(AA[:xxx[:yyy[:nnn]]]); El:
(Registered): (AA[:xxx[:yyy[:nnn]]]);
(AA[:xxx[:yyy[:nnn]]]); SP:(AA[:xxx[:yyy[:nnn]]]):S
U: (AA|:xxx|:yyy| nn|||):
[Registered):(AA[:xxx[:yyy[
:nnn]]])
where AA is the appropriate
PRIMARY__PROVIDER__CODE,
SELLER__CODE; or
CUSTOMER__CODE, 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 ANC__SVC__TYPE:
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

[[Page 38997]]

--``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 (ASSIGNMENT__REF)
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.
ANC__SVC__REQ..................... ANCSVCREQ............ 1(ALPHANUMERIC)100.................... EI: (M.R.O.U); SP; Ancillary services required
(M.R.O.U);. for a transmission
SU: (M.R.O.U); services offering. The
RV: (M.R.O.U): appropriate letter
RF: (M.R.O.U); (M.R.O.U) will be assigned
SC: (M.R.O.U): to each of the six
(registered): (M.R.O.U) Proforma FERC ancillary
services (see
ANC__SERVICE__TYPE), 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.
ALTERNATE__SERVICE__FLAG.......... 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.

[[Page 38998]]

ASSIGNMENT__REF................... 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
START__TIME to an
STOP__TIME.
BID__PRICE........................ BIDPR................ 1(NUMERIC)5 +``.''.................... Positive number with 2 The current bid price of a
+2(NUMERIC)12........................ decimals. Service in dollars and
cents. Used by Customers
to designate a price being
bid.
CAPACITY.......................... CAP.................. 1(NUMERIC)12.......................... Non-negative number in Transfer capability is the
units of MW. 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.
CAPACITY__CURTAILED............... CAPCUR............... 1(NUMERIC)12.......................... Non-negative number in The amount of transfer
units of MW. capability curtailed by
the Primary provider for
emergency reasons.
CAPACITY__SCHEDULED............... CAPSCH............... 1(NUMERIC)12.......................... Non-negative number in Transfer capability
units of MW. scheduled on each path.
CATEGORY.......................... CAT.................. 1(ALPHANUMERIC)25..................... Valid name from CATEGORY A name to be used to
in LIST Template. categorize messages. Valid
names would include:
Discount, Want-Ad,
Curtailment, Outage, Oasis
Maint Notice.
CELING__PRICE..................... CEILPR............... 1(NUMERIC)5 + ``.'' + 2(NUMERIC)2..... Positive number with 2 Ceiling price of the
decimals.. Service as entered by the
Transmission Provider.
COLUMN__HEADERS................... HEADERS.............. 1(ALPHANUMERIC) Limited to all the Headers surrounded with Example: COLUMN__HEADER=
elements nameS in one Template. A and separated by APATH__NAME'',
commas. Limited to POINT__OF__RECEIPT'',
valid Template element POINT__ OF__DELIVERY'',
names. Must use full ``SOURCE'', ``SINK''.
element name and not
alias.
CONTINUATION__FLAG................ CONT................. 1(ALPHANUMERIC)1...................... ``Y'' OR ``N''.......... Indicates whether or not
this record is a
continuation from the
previous record.
CONTROL__AREA..................... AREA................. 1(ALPHANUMERIC)20..................... Valid name of a control A part of the power system
area. with metered tie lines and
capable of matching
generation and load while
meeting scheduled
interchange. Location of
Ancillary services is my
CONROL__AREA.
CURTAILMENT__OPTIONS.............. CUROPT............... 1(ALPHANUMERIC)80..................... Free form text.......... Customer options, if any,
to avoid curtailment.
CURTAILMENT__PROCEDURES........... CURPROC.............. (ALPHANUMERIC)80...................... Free form text.......... Curtailment procedures to
be followed in the event
of a curtailment.
CURTAILMENT__REASON............... CURREAS.............. (ALPHANUMERIC)80...................... Free form text.......... Reason for curtailment of
service.
CUSTOMER__CODE.................... CUST................. 1(ALPHANUMERIC)6...................... Unique value, registered Any entity (or its
on TSIN.COM. designated agent) that is
eligible to view OASIS
information, to execute a
service agreement, and/or
to receive transmission
service.
CUSTOMER__COMMENTS................ CUSTCOM.............. 1(ALPHANUMERIC)80..................... Free-form text.......... Informative text.
CUSTOMER__DUNS.................... CUSTDUNS............. 9(NUMERIC)9........................... Unique DUNS number...... Unique DUNS number for a
Customer.
CUSTOMER__EMAIL................... CUSTEMAIL............ 1(ALPHANUMERIC)25..................... Valid Internet E-Mail Internet E-Mail address of
address. Customer contract person.

[[Page 38999]]

CUSTOMER__FAX..................... CUSTEFAX............. 14(ALPHANUMERIC)20.................... Area code and telephone Fax phone number of
number, plus any Customer contract person.
extensions (aaa)-nnn-
nnnn xnnnn.
CUSTOMER__NAME.................... CUSTNAME............. (ALPHANUMERIC)25...................... Free form text.......... Name of Customer contract
person.
CUSTOMER__PHONE................... CUSTPHON............. 14(ALPHANUMERIC)20.................... Area code and telephone Telephone of Customer
number, plus any contact person.
extensions (aaa)-nnn-
nnnn xnnnn.
DATA__ROWS........................ 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.
DATE__TIME__EFFECTIVE............. TIMEEFCT............. 16(ALPHANUMERIC)16.................... Valid date and time in Date and time a message or
seconds yyyy+mo+dd+hh service offer is in
+mm+ss+tz. effect.
DATE__TIME__POSTED................ TIMEPSTD............. 16(ALPHANUMERIC)16.................... Valid date and time in Date and time to seconds a
seconds yyyy+mo+dd+hh message or service offered
+mm+ss+tz. was posted.
DEAL__REF......................... DREF................. 1(ALPHANUMERIC)12..................... Unique value, Assigned The unique reference
by Customer. 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 DEAL__REF to uniquely
identify a combination of
requests relating to a
particular deal.
DISCRETION__DESCRIPTION........... DISCDESC............. 0(ALPHANUMERIC)1000................... Free form text.......... A detailed description of
the discretion being
reported.
ELEMENT__NAME..................... ELEMENT.............. 1(ALPHANUMERIC)40..................... Valid Template element Template element name as
name. indicated in data
dictionary.
EMPLOYEE__NAME.................... EMPNAME.............. 1(ALPHANUMERIC)25..................... Free form text.......... Name of person who is
transferring from one
position to another.
ERROR__MESSAGE.................... ERROR................ 1(ALPHANUMERIC)250.................... Free form text.......... Error message related to a
RECORD__STATUS or
REQUEST__STATUS.
FORMER__COMPANY................... FORMCO............... 1(ALPHANUMERIC)25..................... Free form text.......... Former company of the
person who is
transferring.
FORMER__DEPARTMENT................ FORMDEPT............. 1(ALPHANUMERIC)25..................... Free form text.......... Former department of the
person who is
transferring.
FORMER__POSITION.................. FORMPOS.............. 1(ALPHANUMERIC)25..................... Free form text.......... Former position held by the
person who is
transferring.
INTERFACE__TYPE................... 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.
LIST__ITEM........................ 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
SERVICE__INCREMENT,
TS__CLASS, TS__TYPE,
TS__PERIOD, NERC__
CURTAILMENT__PRIORITY,
OTHER__CURTAILMENT__
PRIORITY,
SERVICE__INCREMENT,
CATEGORY List of
TEMPLATEs.
LIST__ITEM__ DESCRIPTION.......... ITEMDESC............. 0(ALPHANUMERIC)100.................... Free form text.......... A detailed description of
the LIST__ITEM.

[[Page 39000]]

LIST__NAME........................ LIST................. 1(alphanumeric)25..................... LIST, SELLER, PATH, POR, List of valid names for
POD, each of the types of
SERVICE__INCREMENT, lists. The minimum set of
TS__CLASS, TS__TYPE, lists defined must be
TS__ PERIOD, implemented.
TS__SUBCLASS,
ANCILLARY__ SERVICE__
TYPE, CATEGORY,
TEMPLATE.
MESSAGE........................... MSG.................. 1(ALPHANUMERIC)200................... Free form text.......... An informative text
message.
NEGOTIATED__PRICE__FLAG........... NGPRIFLG............. 1(ALPHANUMERIC)1...................... H, L, or blank.......... Set to H if OFFER__PRICE is
higher than the currently
posted price; set to L if
OFFER__PRICE is lower than
the currently posted
price.
NERC__CURTAINMENT__ PRIORITY...... NERCURT.............. 1(NUMERIC)1........................... Integer 1-7............. One of the NERC seven
curtailment priorities,
documented in LIST
templat.
NEW__COMPANY...................... NEWCO................ 1(ALPHANUMERIC)25..................... Free form text.......... New company of the person
who is transferring.
NEW__DATA......................... NEWDATA.............. 1(ALPHANUMERIC)200.................... Any valid date element For audit log, the new
value. updated value of a
Template data element
after update.
NEW__DEPARTMENT................... NEWDEPT.............. 1(ALPHANUMERIC)25..................... Free form text.......... New department of the
person who is
transferring.
NEW__POSITION..................... NEWPOS............... 1(ALPHANUMERIC)25..................... Free form text.......... New position held by the
person who is
transferring.
OFFER__PRICE...................... OFFPR................ 1(NUMERIC)5 + ``.'' + 2(NUMERIC)2..... Positive number with 2 The current offered price
decimals. of a Service in dollars
and cents. Used by the
Seller to indicate the
offering price.
OFFER__START__TIME................ OFFSTIME............. 16(ALPHANUMERIC)16.................... Valid Date and Time to Start time of the window
seconds:. during which a Customer
yyyy+mo+dd+hh+mmm+ ss+tz may request a discounted
offer.
OFFER__ STOP__TIME................ OFFSPTIME............ 16(ALPHANUMERIC)16.................... Valid Date and Time to Stop time of the window
seconds: during which a Customer
yyyy+mo+dd+hh may request a discounted
+mm+ss+tz. offer. (Expiration time of
an offer).
OLD__DATA......................... OLDDATA.............. 1(ALPHANUMERIC)200.................... Any valid data element For audit log, the old
value. value of a Template data
element prior to being
updated. This element is
not applicable in the
audit log for transaction
events.
OPTIONAL__CODE.................... N/A.................. 0(ALPHANUMERIC)25..................... Unique path name within OPTIONAL__CODE--25 chars,
region. 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 PATH__NAME.
OTHER__CURTAILMENT __PRIORITY..... 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.
OUTPUT__FORMAT.................... 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.
PATH__CODE........................ N/A.................. 0(ALPHANUMERIC)12..................... Unique code for each Unique code within a Region
path as defined by for each path. Used by
primary provider. PATH__NAME.

[[Page 39001]]

PATH__NAME........................ 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
OPTION__CODE and
SPARE__CODE:.
REGION__CODE--2 chars,
unique to OASIS System
PRIMARY__PROVIDER__CODE--4
chars, unique within
Region.
PATH__CODE--12 chars,
unique for Primary
Provider.
OPTIONAL__CODE--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
SPARE__CODE--3 chars.
POINT__ OF__DELIVERY.............. POD.................. 1(ALPHANUMERIC)12..................... Unique value within Point of Delivery is one or
Primary Provider. 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.
POINT__OF __RECEIPT............... POR.................. 1(ALPHANUMERIC)12..................... Unique value within Point of Receipt is one or
Primary Provider. 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.
POSTING__NAME..................... POSTNAME............. 1(ALPHANUMERIC)25..................... Free form text.......... Name of person who is
posting the information on
the OASIS.

[[Page 39002]]

POSTING__REF...................... 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.
PRICE__UNITS...................... UNITS................ 1(ALPHA)20............................ Free form text.......... The units used for
CEILING__PRICE,
OFFER__PRICE, and
BID__PRICE.
Examples: $/MWhr, $/MWmonth
PRIMARY__ PROVIDER__COMMENTS...... PPROVCOM............. 1(ALPHANUMERIC)80..................... Free form text.......... Informative text. Usually
entered by the Primary
Provider through a back
end system.
PRIMARY__ PROVIDER__CODE.......... PROVIDER............. 1(ALPHANUMERIC)4...................... Unique code............. Unique code for each
Primary Provider. used by
PATH__NAME and in URL.
Registered as part of URL
at www.tsin.com.
PRIMARY__ PROVIDER__DUNS.......... PPROVDUNS............ 9(NUMERIC)9........................... Valid DUNS number....... Unique code for each
Primary. Provided by Dun
and Bradstreet.
REASSIGNED__ CAPACITY............. RASCAP............... 1(NUMERIC)12.......................... Positive number, cannot The amount of transfer
exceed previous capability that was
assigned capacity. reassigned from one entity
to another.
REASSIGNED__ REF.................. REREF................ 1(ALPHANUMERIC)12..................... Unique value............ When customer makes a
purchase of a transmission
service that was posted
for resale and a new
ASSIGNMENT__REF number is
issued the previous
ASSIGNMENT__REF number now
becomes the
REASSIGNMENT__REF. 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.
REASSIGNED__START__TIME........... RESSTIME............. 16(ALPHANUMERIC)16.................... Valid date and time to Beginning date and time of
seconds: the reassigned
yyyy+mo+dd+hh+tz........ transmission service.
REASSIGNED__STOP__TIME............ RESSPIME............. 16(ALPHANUMERIC)16.................... Valid date and time to Date and time of the end of
hour: the transmission service
yyyy+mo+dd+hh+tz........ that is reassigned to
another User.
RECORD__STATUS.................... RECSTATUS............ 1(NUMERIC)3........................... Error number............ Record status indicating
record was successful or
error code if
unsuccessful.
200=Successful

[[Page 39003]]

REGION__CODE...................... N/A.................. 1(ALPHANUMERIC)2...................... Unique within OASIS Defined for NERC regions,
System. 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.
REQUEST__REF...................... RREF................. 1(ALPHANUMERIC)12..................... Unique value............ A reference uniquely
assigned by a Customer to
a request for service from
a Provider.
REQUEST__STATUS................... RSTATUS.............. 1(NUMERIC)3........................... Error number............ Message status indicating
message was successful (if
all RECORD__STATUS show
success) or error code if
any RECORD__STATUS showed
unsuccessful.
200=Successful.
RESPONSE__TIME__LIMIT............. RESPTL............... 16(ALPHANUMERIC)16.................... Valid date and time to Date and time to seconds by
seconds: when a response must be
yyyy+mo+dd+hh received from a Customer.
+mm+ss+tz...............
RESPONSIBLE__PARTY__NAME.......... PARTNAME............. 1(ALPHANUMERIC)25..................... Free form text.......... The name of the person
responsible for granting
the discretion.
RETURN__TZ........................ TZ................... 2(ALPHANUMERIC)2...................... AD, AS, PD, PS, ED, ES, A time zone code,
MD, MS, CD, CS, UT. 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.
SALE__REF......................... SREF................. 1(ALPHANUMERIC)12..................... Unique value............ Identifier which is set by
seller (including Primary
Provider) when posting a
service for sale.
SELLER__CODE...................... SELLER............... 1(ALPHANUMERIC)6...................... Unique value............ Organization name of
Primary Provider or
Reseller.
SELLER__COMMENTS.................. SELCOM............... 1(ALPHANUMERIC)80..................... Free form text.......... Informative text provided
by the Seller.
SELLER__DUNS...................... SELDUNS.............. 9(NUMERIC)9........................... Valid DUNS number....... Unique Data Universal
Numbering System provided
by Dun and Bradstreet.
Code for a Primary
Provider or Seller.
SELLER__EMAIL..................... SELEMAIL............. 5(ALPHANUMERIC)60..................... Valid network reference. E-Mail address of Seller
contact person.
SERVICE__INCREMENT................ SRVINCR.............. 1(ALPHANUMERIC)8...................... Valid increments The transmission service
HOURLY increments provided. Five
Daily are pre-defined, while
Weekly additional increments can
Monthly be used if they are
Yearly registered on TSIN.COM and
{Registered} shown in the Provider's
LIST template.
SELLER__FAX....................... SELFAX............... 14(ALPHANUMERIC)20.................... Area code and telephone The fax telephone number
number, plus any for contact person at
extensions Example: Seller.
(aaa)-nnn-nnnn-xnnnn.
SELLER__NAME...................... SELNAME.............. 1(ALPHANUMERIC)25..................... Free form text.......... The name an individual
contact person at the
Seller.
SELLER__PHONE..................... SELPHONE............. 14(ALPHANUMERIC)25.................... Free form text.......... The telephone number of a
contact person as a
Seller.
SERVICE__DESCRIPTION.............. SVCDESC.............. 1(ALPHANUMERIC)200.................... Free form text.......... Information regarding a
service.
SERVICE__NAME..................... SVCNAME.............. 1(ALPHANUMERIC)25..................... Free form text.......... Name of service affected by
the discretionary action.
SERVICE__TYPE..................... SVCTYPE.............. 1(ALPHANUMERIC)25..................... Free form text.......... Type of service affected by
the discretionary action.

[[Page 39004]]

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.
SPARE__CODE....................... N/A.................. 0(ALPHANUMERIC)3...................... Defined by region....... Spare code to be used at a
later time. Used by
PATH__NAME.
STANDARDS__ OF__ CONDUCT__ISSUE... STDISSUE............. 0(ALPHANUMERIC)200.................... Free form text.......... Issues that were in
violation of the FERC
Standards of Conduct.
START__TIME....................... STIME................ 16(ALPHANUMERIC)16.................... Valid date and time to Start date and clock time
seconds: of a service. When used as
yyyy+mo+dd+hh a query variable, it
+mm+ss+tz 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.
START__ TIME__ POSTED............. STIMEP............... 16(ALPHANUMERIC)16.................... Valid Date and Time to Query parameter to indicate
seconds: all the records are to be
xlyyyy+mo+dd+hh......... retrieved that were posted
+mm+ss+tz on or after this time.
START__ TIME__ QUEUED............. STIMEQ............... 16(ALPHANUMERIC)16.................... Valid Date and Time to Start date and clock time
seconds: of a service, used for
yyyy+mo+dd+hh requesting transactions
+mm+ss+tz queued after this time.
STATUS............................ STATUS............... 5(ALPHANUMERIC)25..................... Valid field (QUEUED, QUEUED=initial status
RECEIVED, STUDY, REBID, assigned by TSIP on
OFFER, ACCEPTED, receipt of ``customer
REFUSED, CONFIRMED, capacity purchase
WITHDRAWN, DISPLACED, request''.
ANNULLED, RETRACTED). 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
OFFER__PRICE is being
proposed.
REBID=assigned by TC to
indicate a new BID__PRICE
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,
SELLER__COMMENTS should be
used to communicate reason
for denial of service.

[[Page 39005]]

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.
STATUS__COMMENTS.................. STACOM............... 1(ALPHANUMERIC)80..................... Free form text.......... Informative text.
STATUS__NOTIFICATION.............. STATNOT.............. 1(ALPHANUMERIC)200.................... http://URL:portnumber/ The STATUS__NOTIFICATION
directr y/cgi script/ data element shall contain
query parameters or the rptocol field
Mailto: . 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.
STOP__TIME........................ SPTIME............... 16(ALPHANUMERIC)16.................... Valid date and time yyyy Stop date and clock time.
+ mo + ddd + hh + mm + When used as a query
ss+tz. 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 STOP__TIME.
STOP__TIME__POSTED................ STPTIMEP............. 16(ALPHANUMERIC)16.................... Valid Date and Time to Query parameter to indicate
seconds: all the records are to be
yyyy+mo+dd+hh+mm+ ss+tz. retrieved that were posted
on or before this time.
STOP__TIME__QUEUED................ SPTIMEQ.............. 16(ALPHANUMERIC)16.................... Valid Date and Time to Stop date and clock time,
seconds: used for requesting
yyyy+mo+dd+hh+mm+ ss+tz. transactions queued before
this time.

[[Page 39006]]

SUBJECT........................... SUBJ................. 1(ALPHANUMERIC)80..................... Free form text.......... Informative text used to
summarize a topic in a
message.
TARIFF__REFERENCE................. TARIFF............... 1(ALPHANUMERIC)150.................... Free form text. Name and Tariffs approved by FERC.
description of Tariff.
TEMPLATE.......................... TEMPL................ 1(ALPHANUMERIC)20..................... Valid Name of Template The name of a logical
from Section 4.3 or collection of
from LIST Template. DATA__ELEMENTS in a User's
interaction with an OASIS
Node.
TIME__OF__LAST__UPDATE............ TLUPDATE............. 16(ALPHANUMERIC)16.................... Valid Date and Time to Date and time to seconds
seconds: that data was last
yyyy+mo+dd+hh+mm+ ss+tz. updated. May be used to
search data updated since
a specific point in time.
TIME__POSTED...................... TIMEPST.............. 16(ALPHANUMERIC)16.................... Valid Date and Time to Date and time a message is
seconds: posted.
yyyy+mo+dd+hh+mm+ ss+tz.
TIME__QUEUED...................... TIMEQ................ 16(ALPHANUMERIC)16.................... Valid Date and Time to Date and time that the
seconds: request was queued.
yyyy+mo+dd+hh+mm+ ss+tz.
TIME__STAMP....................... TSTAMP............... 16(ALPHANUMERIC)16.................... Valid Date and Time to Time data is created.
seconds:
yyyy+mo+dd+hh+mm+ ss+tz.
TS__CLASS......................... TSCLASS.............. 1(ALPHANUMERIC)20..................... Valid classes:.......... The transmission service
FIRM classes provided. Three
NON-FIRM are pre-defined, while
TTC additional classes can be
(Registered) used if they are
registered on TSIN.COM and
shown in the Provider's
LIST template page.
TS__PERIOD........................ TSPER................ 1(ALPHANUMERIC)20..................... Valid periods:.......... The transmission service
ON__PEAK periods provided. Three
OFF__PEAK are pre-defined, while
FULL__PERIOD additional periods can be
(Registered) used if they are
registered on TSIN.COM and
shown in the Provider's
LIST template.
--------------------------------------------------------------------------------------------------------------------------------------------------------

[[Page 39007]]

--------------------------------------------------------------------------------------------------------------------------------------------------------
Field format: minimum characters (type
Data dictionary element name Alias of ASCII) maximum characters Restricted values Definition of data element
--------------------------------------------------------------------------------------------------------------------------------------------------------
TS__SUBCLASS...................... TSSUBC............... 1(ALPHANUMERIC)20..................... Free form............... The transmission service
subclasses provided. These
are freeform.
TS__TYPE.......................... TSTYPE............... 1(ALPHANUMERIC)20..................... Valid periods:.......... The transmission service
POINT__TO__POIN types provided. Two are
T pre-defined, while
NETWORK additional types can be
(Registered) used if they are
registered on TSIN.COM and
shown in the Provider's
LIST template.
TS__WINDOW........................ TSWIND............... 1(ALPHANUMERIC)20..................... Valid periods:.......... The transmission service
FIXED windows provided. Two are
SLIDING pre-defined, while
(Registered) 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 Time zones:
indication whether Atlantic time=AD, AS.
daylight savings time Eastern time=ED, ES.
is to be used. Central time=CD, CS.
Mountain time=MD, MS.
Pacific time=PD, PS.
Universal time=UT.
VALID__FROM__TIME................. VALFTIME............. 16(ALPHANUMERIC)16.................... Valid Date and Time Date and time after which
yyyy+mo+dd+hh+mm+ ss+tz. the message is valid.
VALID__TO__TIME................... VALTTIME............. 16(ALPHANUMERIC)16.................... Valid date and time Date and time before which
yyyy+mo+dd+hh+mm+ ss+tz. 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