[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 <a href="/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="8fcce6fffcc2eefcfbeafdcfc9caddcca1e9eaeba1fafca1">[email protected]</a>
    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 <a href="/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="d98bb0b4aa94b8aaadbcab999f9c8b9af7bfbcbdf7acaaf7">[email protected]</a>
    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).<SUP>1</SUP> The

[[Page 38885]]

current Phase I OASIS is an Internet-based electronic communication and 
reservation system through which transmission providers <SUP>2</SUP> 
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.<SUP>3</SUP> 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) <SUP>4</SUP> to develop suitable 
OASIS standards and communications protocols.<SUP>5</SUP> 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.<SUP>6</SUP>
---------------------------------------------------------------------------

    \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,<SUP>7</SUP> 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.<SUP>8</SUP> 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 <SUP>9</SUP> 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.<SUP>10</SUP> 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''.<SUP>11</SUP>
---------------------------------------------------------------------------

    \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.<SUP>12</SUP> 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''.<SUP>13</SUP>
---------------------------------------------------------------------------

    \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:
    <bullet> 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.
    <bullet> 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.<SUP>21</SUP> 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.<SUP>22</SUP>
---------------------------------------------------------------------------

    \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.<SUP>23</SUP> 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.<SUP>24</SUP>
---------------------------------------------------------------------------

    \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.<SUP>25</SUP> NYSEG shares the view that electricity markets may 
become more efficient with more transmission information made available 
on a non-discriminatory basis.<SUP>26</SUP>
---------------------------------------------------------------------------

    \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.<SUP>27</SUP> 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.<SUP>28</SUP> 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.<SUP>29</SUP> EPSA foresees the 
competitiveness of electricity markets being undermined by unmasking, 
with markets eventually returning to monopoly power suppliers and 
captive power purchasers.<SUP>30</SUP> CPEX also sees unmasking as a 
serious threat to competitive electricity markets.<SUP>31</SUP>
---------------------------------------------------------------------------

    \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.<SUP>32</SUP> 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.<SUP>33</SUP> 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.<SUP>34</SUP> 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.<SUP>35</SUP>
---------------------------------------------------------------------------

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

    \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.<SUP>39</SUP> 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.<SUP>40</SUP> 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.<SUP>41</SUP>
---------------------------------------------------------------------------

    \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,<SUP>42</SUP> PJM sees unmasking making no 
difference.<SUP>43</SUP> 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.<SUP>44</SUP> 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.<SUP>45</SUP>
---------------------------------------------------------------------------

    \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.<SUP>46</SUP>
---------------------------------------------------------------------------

    \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 <SUP>47</SUP> 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.<SUP>48</SUP>
---------------------------------------------------------------------------

    \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.<SUP>49</SUP> 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.<SUP>50</SUP> 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.<SUP>51</SUP> 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.<SUP>52</SUP> 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.<SUP>53</SUP> 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).<SUP>54</SUP>
---------------------------------------------------------------------------

    \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.<SUP>55</SUP>
---------------------------------------------------------------------------

    \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.<SUP>56</SUP>
---------------------------------------------------------------------------

    \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.<SUP>57</SUP>
---------------------------------------------------------------------------

    \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.<SUP>58</SUP>
---------------------------------------------------------------------------

    \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.<SUP>59</SUP> 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,<SUP>60</SUP> 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.<SUP>61</SUP> Under this limited interim procedure, wherein we 
merely allow the price field to be modified,<SUP>62</SUP> 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.<SUP>63</SUP> 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.<SUP>64</SUP> 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.<SUP>65</SUP> 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; <SUP>66</SUP> 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.<SUP>67</SUP>
---------------------------------------------------------------------------

    \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.<SUP>68</SUP>
---------------------------------------------------------------------------

    \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.<SUP>69</SUP>
---------------------------------------------------------------------------

    \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.<SUP>70</SUP>
---------------------------------------------------------------------------

    \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.<SUP>71</SUP>
---------------------------------------------------------------------------

    \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.<SUP>72</SUP>
---------------------------------------------------------------------------

    \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.<SUP>73</SUP> 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.<SUP>74</SUP> 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.<SUP>75</SUP>
---------------------------------------------------------------------------

    \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.<SUP>76</SUP> 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.<SUP>77</SUP>
---------------------------------------------------------------------------

    \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.<SUP>78</SUP> 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.<SUP>79</SUP> 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.<SUP>80</SUP>
---------------------------------------------------------------------------

    \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.<SUP>81</SUP> 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.<SUP>82</SUP>
---------------------------------------------------------------------------

    \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.<SUP>83</SUP>
---------------------------------------------------------------------------

    \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.<SUP>84</SUP>
---------------------------------------------------------------------------

    \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.<SUP>92</SUP> 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.<SUP>93</SUP> 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.<SUP>94</SUP> 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

    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.

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

    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,

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

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

[[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 <return> 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:
    <bullet> Text strings that do not contain commas (,) or double 
quotes (``) shall be accepted both with and without being enclosed by 
double quotes.
    <bullet> 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 (````).
    <bullet> 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.
    <bullet> 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.
    <bullet> 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):
    <bullet> 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.
    <bullet> 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:

<bullet> Company
<bullet> Name
<bullet> Phone
<bullet> Fax
<bullet> 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: <byte count of remainder of message>
REQUEST__STATUS=200
TIME__STAMP=<appropriate value>
VERSION=1.2
TEMPLATE=transstatus
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=ABC
PRIMARY__PROVIDER__DUNS=123456789
RETURN__TZ=<appropriate value for ABC>
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.

<bullet> SC-Scheduling, system Control and dispatch
<bullet> RV-Reactive supply and Voltage control
<bullet> RF-Regulation and Frequency response
<bullet> EI-Energy Imbalance
<bullet> SP-Spinning reserve
<bullet> SU-Supplemental reserve

and where x-(M,R,O,U) means one of the following:

<bullet> Mandatory, which implies that the Primary Provider must 
provide the ancillary service
<bullet> Required, which implies that the ancillary service is 
required, but not necessarily from the Primary Provider
<bullet> Optional, which implies that the ancillary service is not 
necessarily required, but could be provided
<bullet> 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]]

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 (Start time of curtailment)
CAPACITY (Capacity reserved)
CAPACITY__SCHEDULED
CAPACITY__CURTAILED
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__WINDOW
TS__SUBCLASS
HERC__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 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<return> (Successful)
TIME__STAMP=19960409113526PD<return>
VERSION=1.2<return>
TEMPLATE=transoffering<return>
OUTPUT__FORMAT=DATA<return>
PRIMARY__PROVIDER__CODE=AAAA<return>
PRIMARY__PROVIDER__DUNS=123456789<return>
DATA__ROWS=14<return>
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<return>
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<return>
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<return>
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<return>
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<return>
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<return>
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<return>
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<return>
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<return>
. . .
. . .
. . .
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<return>
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<return>
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<return>

[[Page 38934]]

TIME__STAMP=19960410114702PD<return>
VERSION-1.2<return>
TEMPLATE=schedule<return>
OUTPUT__FORMAT=DATA<return>
PRIMARY__PROVIDER__CODE=AAAA<return>
PRIMARY__PROVIDER__DUNS=123456789<return>
DATA__ROWS=5<return>
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<return>
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<return>
. . .<return>
. . .<return>
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<return>
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<return>
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<return>
TEMPLATE=transpost<return>
OUTPUT__ FORMAT=DATA<return>
PRIMARY__ PROVIDER__ CODE=AAAA<return>
PRIMARY__ PROVIDER__ DUNS=123456789<return>
DATA__ ROWS=1<return>
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<return>
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''''''<return>
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<return>(Successful)
TIME__ STAMP=19960409113526PD<return>
VERSION-1.2<return>
TEMPLATE=transpost<return>
OUTPUT__ FORMAT=DATA<return>
PRIMARY__PROVIDER__ CODE=AAAA<return>
PRIMARY__ PROVIDER__ DUNS=123456789<return>
DATA__ ROWS=1<return>
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<return>
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<return>
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''<return>
CUSTOMER__CODE=``BestE''<return>
CAPACITY=150<return>
TS__CLASS=``FIRM''<return>
START__TIME=``1996050708000000PD''<return>

[[Page 38935]]

STOP__TIME=``1996050717000000PD''<return>
BID__PRICE=``$1.00''<return>
    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''<return>
CUSTOMER__CODE=``BestE''<return>
CAPACITY=120<return>
TS__CLASS=``NON-FIRM''<return>
START__TIME=``1996050715000000PD''<return>
STOP__TIME=``1996050721000000PD''<return>
BID__PRICE=``$1.05''<return>
    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''<return>
SELLER__CODE=``BestE''<return>
CAPACITY=100<return>
TS__CLASS=``NON-FIRM''<return>
START__TIME=``1996050708000000PD''<return>
STOP__TIME=``1996050721000000PD''<return>
SALE__REF=``BEST100''<return>
OFFER__PRICE=.90<return>
SELLER__COMMENTS=``aggregating two previous purchases''<return>
    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''<return>
CUSTOMER__CODE=``Whlsle''<return>
SELLER__CODE=``BestE''<return>
CAPACITY=100<return>
TS__CLASS=``NON-FIRM''<return>
START__TIME=``1996050708000000PD''<return>
STOP__TIME=``1996050721000000PD''<return>
SALE__REF=``BEST100''<return>
DEAL__REF=``WPC100''<return>
BID__PRICE=.90<return>
CUSTOMER__COMMENTS=``Only need service until 6 p.m.''<return>
    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''<return>
CUSTOMER__CODE=``Whlsle''<return>
SELLER__CODE=``BestE''<return>
ASSIGNMENT__REF=5002<return>
STATUS=``Accepted''<return>
REASSIGNED__REF1=5000<return>
REASSIGNED__CAPACITY1=100<return>
REASSIGNED__START__TIME1=``199605070800PD''<return>
REASSIGNED__STOP__TIME1=``199605071700PD''<return>
REASSIGNED__REF2=5001<return>
REASSIGNED__CAPACITY2=100<return>
REASSIGNED__START__TIME2=``199605071700PD''<return>
REASSIGNED__STOP__TIME2=``199605071800PD''<return>
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<return>

[[Page 38936]]

TEMPLATE=transrequest<return>
OUTPUT__FORMAT=DATA<return>
PRIMARY__PROVIDER__CODE=AEP<return>
PRIMARY__PROVIDER__DUNS=123456789<return>
DATA__ROWS=7<return>
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<return>
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<return>
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<return>
Y........10.......19970423070000ES, 19970423080000ES.........Second 
piece<return>
Y........15.......19970423080000ES, 19970423200000ES.........Third 
piece<return>
Y........10.......19970423200000ES, 19970423210000ES.........Fourth 
piece<return>
Y........5........19970423210000ES, 19970423220000ES.........Fifth 
piece<return>
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<return>
Response:
REQUEST__STATUS=200<return>
TIME__STAMP=19970422160523ES<return>
TEMPLATE=transrequest<return>
OUTPUT__FORMAT=DATA<return>
PRIMARY__PROVIDER__CODE=AEP<return>
PRIMARY__PROVIDER__DUNS=123456789<return>
DATA__ROWS=7<return>
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<return>
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<return>
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<return>
200. Y.......10.......19970423070000ES, 19970423080000ES.........Second 
piece. No error<return>
200. Y.......15.......19970423080000ES, 19970423200000ES.........Third 
piece. No error<return>
200. Y.......10.......19970423200000ES, 19970423210000ES.........Fourth 
piece. No error. <return>
200. Y.......5........19970423210000ES, 19970423220000ES.........Fifth 
piece. No error. <return>
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<return>
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<return>
TEMPLATE=transsell<return>
OUTPUT__FORMAT=DATA<return>
PRIMARY__PROVIDER__CODE=AEP<return>

[[Page 38937]]

PRIMARY__PROVIDER__DUNS=123456789<return>
DATA__ROW=3<return>
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<return>
200. Y.......7880. 10. 19970423080000ES. 19970423160000ES<return>
200. Y.......7019. 10. 19970423080000ES. 19970423160000ES<return>
Response:
VERSION=1.2<return>
TEMPLATE=transsell<return>
OUTPUT__FORMAT=DATA<return>
PRIMARY__PROVIDER__CODE=AEP<return>
PRIMARY__PROVIDER__DUNS=123456789<return>
DATA__ROW=3<return>
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<return>
200. Y.......7880. 10. 19970423080000ES. 19970423160000ES<return>
200. Y.......7019. 10. 19970423080000ES. 19970423160000ES<return>
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<return>
TEMPLATE=transassign<return>
OUTPUT__FORMAT=DATA<return>
PRIMARY__PROVIDER__CODE=AEP<return>
PRIMARY__PROVIDER__DUNS=123456789<return>
DATA__ROWS=2<return>
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<return>
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<return>
Y...........10......19970423220000ES. 19970424000000ES.......7019. 10. 
19970423220000ES. 19970424000000ES<return>
Response:
REQUEST__STATUS=200<return>
TIME__STAMP=19970422144520ES<return>
VERSION=1.2<return>
TEMPLATE=transassign<return>
OUTPUT__FORMAT=DATA<return>
PRIMARY__PROVIDER__CODE=AEP<return>
PRIMARY__PROVIDER__DUNS=123456789<return>
DATA__ROWS=2<return>
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<return>
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.<return>
200, Y............10......19970423220000ES, 19970424000000ES......7019, 
10, 19970423220000ES, 19970424000000ES..<return>
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:
<appropriate query name/value pairs to return reservations for 4/23>
Response:
REQUEST__STATUS=200<return>
TIME__STAMP=19970423040523ES<return>
TEMPLATE=transstatus<return>
OUTPUT__FORMAT=DATA<return>
PRIMARY__PROVIDER__CODE=AEP<return>
PRIMARY__PROVIDER__DUNS=123456789<return>
DATA__ROWS=11<return>
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, <a href="/cdn-cgi/l/email-protection#7c160f111508143c040506521f1311"><span class="__cf_email__" data-cfemail="e389908e8a978ba39b9a99cd808c8e">[email protected]</span></a>. Jane Doe, (999)-123-4567, (999)-123-
8823..7019, 10, 19970423000000ES. 19970423060000ES<return>
Y,,,,,,,,,,,,,10,,,,,,19970423220000ES, 
19970424000000ES..............7019, 10, 19970423220000ES, 
19970424000000ES<return>
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,<a href="/cdn-cgi/l/email-protection#3a504957534e527a42434214595557"><span class="__cf_email__" data-cfemail="1d776e707469755d656465337e7270">[email protected]</span></a>, Jane Doe, (999)-123-4567, (999)-
123-8823..7019, 10, 19970423000000ES, 19970423060000ES<return>
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, <a href="/cdn-cgi/l/email-protection#650f16080c110d251d1c1f4b060a08"><span class="__cf_email__" data-cfemail="d0baa3bdb9a4b890a8a9aafeb3bfbd">[email protected]</span></a>.Jane Doe (999)-123-4567, (999)-123-8823..7019, 
10, 19970423000000ES, 19970423060000ES<return>
Y............10.......19970423070000ES, 
19970423080000ES.........................<return>
Y............15.......19970423080000ES, 
19970423200000ES.........................<return>
Y............10.......19970423200000ES, 
19970423210000ES.........................<return>
Y............5........19970423210000ES, 
19970423220000ES.........................<return>
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, <a href="/cdn-cgi/l/email-protection#8ae0f9e7e3fee2caf2f3f0a4e9e5e7"><span class="__cf_email__" data-cfemail="86ecf5ebeff2eec6fefffca8e5e9eb">[email protected]</span></a>, Jane Doe, 
(999)-123-4567, (999)-123-8823..7019, 20, 19970423040000ES, 
199704230080000ES<return>
Y......................................7880.10.......19970423080000ES, 
19970423160000ES<return>
Y......................................7019.10......19970423080000ES, 
19970423160000ES<return>
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:
    <bullet> The response capabilities of the OASIS Node server to 
process interactions with Users.
    <bullet> 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:
    <greek-S> 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:
    <greek-S> 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:
    <bullet> Disk drive or other storage device
    <bullet> Processor
    <bullet> Inter-processor communications (e.g., LAN)
    <bullet> Inter-OASIS communications
    <bullet> Software application
    <bullet> Database
    <bullet> Communication ports for access by Users
    <bullet> 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.       
                                                                                                     <bullet> EL..........  EP--Spinning Reserve.       
                                                                                                     <bullet> SP..........  SU--Supplemental Reserve.   
                                                                                                     <bullet> SU..........  RV--Reactive supply and     
                                                                                                                             Voltage Control.           
                                                                                                     <bullet> RV..........  RF--Regulation and Frequency
                                                                                                                             response.                  
                                                                                                     <bullet> RF..........  SC--Scheduling, system      
                                                                                                                             Control and Dispatch.      
                                                                                                     <bullet> SC..........  (Registered) must be        
                                                                                                                             registered with            
                                                                                                                             www.tsin.com and listed in 
                                                                                                                             the ANCSERV template.      
                                                                                                     <bullet> (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    
                                                                                                     <bullet> HOURLY         increments provided. Five  
                                                                                                     <bullet> Daily          are pre-defined, while     
                                                                                                     <bullet> Weekly         additional increments can  
                                                                                                     <bullet> Monthly        be used if they are        
                                                                                                     <bullet> Yearly         registered on TSIN.COM and 
                                                                                                     <bullet> [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: <e-mail        the notification method/   
                                                                                                      address.>.             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    
                                                                                                     <bullet> FIRM           classes provided. Three are
                                                                                                     <bullet> NON-FIRM       predefined, while          
                                                                                                     <bullet> TTC            additional classes can be  
                                                                                                     <bullet> (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    
                                                                                                     <bullet> POINT__TO__P   types provided. Two are    
                                                                                                      OINT                   predefined, while          
                                                                                                     <bullet> NETWORK        additional types can be    
                                                                                                     <bullet> (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    
                                                                                                     <bullet> FIXED          windows provided. Two are  
                                                                                                     <bullet> SLIDING        predefined, while          
                                                                                                     <bullet> (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

    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.

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

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

    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

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

    a. General Message & Log: TSIPs shall post a general message and 
log that may be read by Users. The message shall state that the 
Provider has updated some information, and shall contain (or point to) 
a reverse chronological log of those changes. This log may be the same 
as the Audit Log. The User may use the manual capability to see the 
message.
    b. TSIP Notification Design Responsibilities: The TSIP shall avoid 
a design that could cause serious performance problems by necessitating 
frequent requests for information from many Users.

3.6  User Interaction with an OASIS Node

    There are three basic types of User interactions which must be 
supported by the OASIS Node. These interactions are defined in Section 
4.3.
    a. Query/Response: The simplest level of interactions is the query 
of posted information and the corresponding response. The User may 
determine the scope of the information queried by specifying values, 
through an HTML form, a URL string, or an uploaded file, using Query 
Variables and their associated input values as defined with each 
Template in Section 4.3. The response will be either an HTML display or 
a record oriented file, depending on the output format that the User 
requests.
    The TSIP may establish procedures to restrict the size of the 
response, if an overly broad query could result in a response which 
degrades the overall performance of the OASIS Node for their Users.
    b. Purchase Request: The second type of Customer interaction is the 
submittal of a request to purchase a service. The Customer completes an 
input form, a URL string or uploads a file and submits it to the OASIS 
Node. The uploaded file can either be a series of query variables or a 
record oriented file.
    The request is processed by the Seller of the service, possibly 
off-line from the OASIS Node, and the status is updated accordingly.
    If a purchase request is approved by the Seller, then it must be 
again conformed by the Customer. Once the Customer confirms an approved 
purchase, a reservation for those services is considered to exist, 
unless later the reservation is reassigned, displaced, or annulled.
    c. Upload and Modify Postings: Customers who wish to resell their 
rights may upload a form, create the appropriate URL or upload a file 
to post services for sale. A similar process applies to eligible Third 
Party Sellers of ancillary services. The products are posted by the 
TSIP. The seller may monitor the status of the services by requesting 
status information. Similarly the Seller may modify its posted 
transmission services by submitting a service modification request 
through a form, a URL query, or by uploading a file.

4. Interface Requirements

4.1  Information Model Concepts

    a. ASCII-Based OASIS Templates: For providing information to Users, 
TSIPs shall use the specified OASIS Templates. These Templates define 
the information which must be presented to Users, both in the form of 
graphical displays and as downloaded files. Users shall be able to 
request Template information using query-response data flows. The OASIS 
Templates are described in section 4.3. The Data Element Dictionary, 
which defines the data elements in the OASIS Templates, is provided in 
Appendix A.
    Data elements must be used in the exact sequence and number as 
shown in the Templates when file uploads and downloads are used. 
Although the contents of the graphical displays are precisely defined 
as the same information as in the Templates, the actual graphical 
display formats of the TS information are beyond the scope of the OASIS

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

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).
    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 <return> 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:
    <bullet> Text strings that do not contain commas (,) or double 
quotes ('') shall be accepted both with and without being enclosed by 
double quotes.
    <bullet> 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 (`` '' ).
    <bullet> 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.
    <bullet> 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.
    <bullet> 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):
    <bullet> 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.
    <bullet> 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:
    <bullet> Company
    <bullet> Name
    <bullet> Phone
    <bullet> Fax
    <bullet> 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:<byte count of remainder of message<ls-thn-eq>
REQUEST__STATUS=200
TIME__STAMP=<appropriate value<ls-thn-eq>
VERSION=1.2
TEMPLATE=transstatus
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=ABC
PRIMARY__PROVIDER__DUNS=123456789
RETURN__TZ=<appropriate value for ABC<ls-thn-eq>
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,
    <bullet> SC--Scheduling, system Control and dispatch
    <bullet> RV--Reactive supply and Voltage control
    <bullet> RF--Regulation and Frequency response
    <bullet> EI--Energy Imbalance
    <bullet> SP--SPinning reserve
    <bullet> SU--SUpplemental reserve

and where x={M,R,O,U} means one of the following:
    <bullet> Mandatory, which implies that the Primary Provider must 
provide the ancillary service
    <bullet> Required, which implies that the ancillary service is 
required, but not necessarily from the Primary Provider
    <bullet> Optional, which implies that the ancillary service is not 
necessarily required, but could be provided
    <bullet> 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<return>(Successful)

[[Page 38987]]

TIME__STAMP=19960409113526PD<return>
VERSION=1.2<return>
TEMPLATE=transoffering<return>
OUTPUT__FORMAT=DATA<return>
PRIMARY__PROVIDER__CODE=AAAA<return>
PRIMARY__PROVIDER__DUNS=123456789<return>
DATA__ROWS=14<return>
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<return>
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<return>
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<return>
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<return>
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<return>
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<return>
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<return>
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<return>
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<return>
. . .
. . .
. . .
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<return>
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<return>
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<return>
TIME__STAMP=1996041014702PD<return>

[[Page 38988]]

VERSION=1.2<return>
TEMPLATE=Schedule<return>
OUTPUT__FORMAT=DATA<return>
PRIMARY__PROVIDER__CODE=AAAA<return>
PRIMARY__PROVIDER__DUNS=123456789<return>
DATA__ROWS=5<return>
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<return>
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<return>
. . .<return>
. . .<return>
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<return>
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<return>
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<return>
TEMPLATE=transpost<return>
OUTPUT__FORMAT=DATE<return>
PRIMARY__PROVIDER__CODE=AAAA<return>
PRIMARY__PROVIDER__DUNS=123456789<return>
DATA__ROWS=1<return>
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<return>
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''''''<return>
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<return> (Successful)
TIME__STAMP=19960409113526PD<return>
VERSION-1.2<return>
TEMPLATE=Transport<return>
OUTPUT__FORMAT=DATA<return>
PRIMARY__PROVIDER__CODE=AAAA<return>
PRIMARY__PROVIDER__DUNS=1234456789<return>
DATA__ROWS=1<return>
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<return>
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<return>
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<return>
CUSTOMER__CODE=BestE<return>
CAPACITY=150<return>
TS__CLASS=``FIRM''<return>

[[Page 38989]]

START TIME=``1996050708000000PD''<return>
STOP__TIME=``1996050717000000PD''<return>
BID__PRICE=``$1.00''<return>
    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''<return>
CUSTOMER__CODE=``BestE''<return>
CAPACITY=120<return>
TS__CLASS=``NON-FIRM''<return>
START__TIME=``1996050715000000PD''<return>
STOP__TIME=``1996050721000000PD''<return>
BID__PRICE=``$1.05''<return>
    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''<return>
SELLER__CODE=``BestE''<return>
CAPACITY=100<return>
TS__CLASS=``NON-FIRM''<return>
START__TIME=``1996050708000000PD''<return>
STOP__TIME=``1996050721000000PD''<return>
SALE__REF=``BEST100''<return>
OFFER__PRICE=.90<return>
SELLER__COMMENTS-``aggregating two previous purchases''<return>
    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''<return>
CUSTOMER__CODE=``Whisle''<return>
SELLER__CODE=``BestE''<return>
CAPACITY__=100<return>
TS__CLASS=``NON-FIRM''<return>
START__TIME=``1996050708000000PD''<return>
STOP__TIME=``1996050721000000PD''<return>
SALE__REF=``BEST100''<return>
DEAL__REF=``WPC100''<return>
BID__PRICE=.90<return>
CUSTOMER__COMMENTS=``Only need service until 6 p.m.''<return>
    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''<return>
CUSTOMER__CODE=``Whisle''<return>
SELLER__CODE=``BestE''<return>
ASSIGNMENT__REF=5002<return>
STATUS=``Accepted''<return>
REASSIGNED__REFI=5000<return>
REASSIGNED__CAPACITY1=100<return>
REASSIGNED__START__TIME1=``199605070800PD''<return>
REASSIGNED__STOP__TIME1=``199605071700PD''<return>
REASSIGNED__REF2=5001<return>
REASSIGNED__CAPACITY2=100<return>
REASSIGNED__START__TIME2=``199605071700PD''<return>
REASSIGNED__STOP__TIME2=``199605071800PD''<return>
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<return>
TEMPLATE=transrequest<return>

[[Page 38990]]

OUTPUT__FORMAT=DATA<return>
PRIMARY__PROVIDER__CODE=AEP<return>
PRIMARY__PROVIDER__DUNS=123456789<return>
DATA__ROWS=7<return>
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<return>
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<return>
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<return>
Y,,,,,,,, 10,,,,,,, 19970423070000ES, 19970423080000ES,,,,,,,,Second 
piece<return>
Y,,,,,,,, 15,,,,,,, 19970423080000ES, 19970423200000ES,,,,,,,,Third 
piece<return>
Y,,,,,,,, 10,,,,,,, 19970423200000ES, 19970423210000ES,,,,,,,,Fourth 
piece<return>
Y,,,,,,,, 5,,,,,,, 19970423210000ES, 19970423220000ES,,,,,,,,Fifth 
piece<return>
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<return>
Response:
REQUEST__STATUS=200<return>
TIME__STAMP=19970422160523ES<return>
TEMPLATE=transrequest<return>
OUTPUT__FORMAT=DATA<return>
PRIMARY__PROVIDER__CODE=AEP<return>
PRIMARY__PROVIDER__DUNS=123456789<return>
DATA__ROWS=7<return>
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<return>
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<return>
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<return>
200, Y,,,,,,,, 10,,,,,,,19970423070000ES, 
19970423080000ES,,,,,,,,,Second piece, No error<return>
200, Y,,,,,,,, 15,,,,,,,19970423080000ES, 
199704232800000ES,,,,,,,,,Third piece, No error<return>
200, Y,,,,,,,, 10,,,,,,,19970423200000ES, 
19970423210000ES,,,,,,,,,Fourth piece, No error<return>
200, Y,,,,,,,, 5,,,,,,,19970423210000ES, 19970423220000ES,,,,,,,,,Fifth 
piece, No error<return>
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<return>
    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<return>
TEMPLATE=transsell<return>
OUTPUT__FORMAT=DATA<return>
PRIMARY__PROVIDER__CODE=AEP<return>
PRIMARY__PROVIDER__DUNS=123456789<return>
DATA__ROWS=3<return>
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<return>
Y,,,,,,,7880, 10, 19970423080000ES, 19970423160000ES<return>
Y,,,,,,,7019, 10, 19970423080000ES, 19970423160000ES<return>
Response:
VERSION=1.2<return>
TEMPLATE=transsell<return>
OUTPUT__FORMAT=DATA<return>
PRIMARY__PROVIDER__CODE=AEP<return>
PRIMARY__PROVIDER__DUNS=123456789<return>
DATA__ROWS=3<return>
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.<return>
200 Y,,,,,,,7880, 10, 19970423080000ES, 19970423160000ES,<return>
200 Y,,,,,,,7019, 10, 19970423080000ES, 19970423160000ES,<return>
    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<return>
TEMPLATE=transassign<return>
OUTPUT__FORMAT=DATA<return>
PRIMARY__PROVIDER__CODE=AEP<return>
PRIMARY__PROVIDER__DUNS=123456789<return>
DATA__ROWS=2<return>
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<return>
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<return>
Y, , , , , , , , , , 10, , , , , , 19970423220000ES, 19970424000000ES, 
, , , , , , 7019, 10, 19970423220000ES, 19970424000000ES<return>
Response:
REQUEST__STATUS=200<return>
TIME__STAMP=19970422144520ES<return>
VERSION=1.2<return>
TEMPLATE=transassign<return>
OUTPUT__FORMAT=DATA<return>
PRIMARY__PROVIDER__CODE=AEP<return>
PRIMARY__PROVIDER__DUNS=123456789<return>
DATA__ROWS=2<return>
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<return>
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,<return>

[[Page 38992]]

200, Y, , , , , , , , , , , , 10, , , , , , 19970423220000ES, 
19970424000000ES,,,,,, 7019, 10, 19970423220000ES, 
19970424000000ES,,<return>
    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:
<appropriate query name/value pairs to return reservations for 4/23>
Response:
REQUEST__STATUS=200<return>
TIME__STAMP=19970423040523ES<return>
TEMPLATE-transstatus<return>
OUTPUT__FORMAT=DATA<return>
PRIMARY__PROVIDER__CODE=AEP<return>
PRIMARY__PROVIDER__DUNS=123456789<return>
DATA__ROWS=11<return>
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, 
<a href="/cdn-cgi/l/email-protection#711b021c1805193109080b5f121e1c"><span class="__cf_email__" data-cfemail="9bf1e8f6f2eff3dbe3e2e1b5f8f4f6">[email protected]</span></a>, Jane Doe, (999)-123-4567, (999)-123-8823, , 7019, 10, 
19970423000000ES, 19970423060000ES<return>
Y, , , , , , , , , , , , , 10, , , , , , 19970423220000ES, 
19970424000000ES, , , , , , , , , , , , , , , , , , , , , ,7019, 10, 
19970423220000ES, 19970424000000ES<return>
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, <a href="/cdn-cgi/l/email-protection#254f56484c514d655d5c5f0b464a48"><span class="__cf_email__" data-cfemail="315b425c5845597149484b1f525e5c">[email protected]</span></a>, Jane Doe, (999)-123-4567, (999)-123-8823, 7019, 
10, 19970423000000ES, 19970423060000ES<return>
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, 
<a href="/cdn-cgi/l/email-protection#c2a8b1afabb6aa82babbb8eca1adaf"><span class="__cf_email__" data-cfemail="2f455c42465b476f575655014c4042">[email protected]</span></a>, Jane Doe, (999)-123-4567, (999)-123-8823,, 7019, 10, 
19970423000000ES, 19970423060000ES<return>
Y, , , , , , , , , , , , , 10, , , , , , ,19970423070000ES, 
1997042380000ES, , , , , , , , , , , , , , , , , , , , , , , , 
,<return>
Y, , , , , , , , , , , , ,15, , , , , , ,19970423080000ES, 
19970423200000ES, , , , , , , , , , , , , , , , , , , , , , , , 
,<return>
Y, , , , , , , , , , , , ,10, , , , , , ,19970423200000ES, 
19970423210000ES, , , , , , , , , , , , , , , , , , , , , , , , 
,<return>
Y, , , , , , , , , , , , ,5, , , , , , ,19970421000000ES, 
19970423220000ES, , , , , , , , , , , , , , , , , , , , , , , , 
,<return>
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<return>
Y, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , 
, , , 7880, 10, , , , , , 19970423080000ES, 19970423160000ES<return>
Y, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , 
, , , 7019, 10, , , , , , 19970423080000ES, 19970423160000ES<return>
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

    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 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:
    <bullet> The response capabilities of the OASIS Node server to 
process interactions with Users
    <bullet> 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 <greek-S> 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 <greek-S> 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:
    <bullet> Disk drive or other storage device
    <bullet> Processor
    <bullet> Inter-processor communications (e.g., LAN)
    <bullet> Inter-OASIS communications
    <bullet> Software application
    <bullet> Database
    <bullet> Communication ports for access by Users
    <bullet> 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 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.      
                                                                                                   <bullet> EL.............  EP--Spinning Reserve.      
                                                                                                   <bullet> SP.............  SU--Supplemental Reserve.  
                                                                                                   <bullet> SU.............  RV--Reactive supply and    
                                                                                                                              Voltage Control.          
                                                                                                   <bullet> RV.............  RF--Regulation and         
                                                                                                                              Frequency response.       
                                                                                                   <bullet> RF.............  SC--Scheduling, system     
                                                                                                                              Control and Dispatch.     
                                                                                                   <bullet> SC.............  (Registered) must be       
                                                                                                                              registered with           
                                                                                                                              www.tsin.com and listed in
                                                                                                                              the ANCSERV template.     
                                                                                                   <bullet> (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   
                                                                                                   <bullet> HOURLY            increments provided. Five 
                                                                                                   <bullet> Daily             are pre-defined, while    
                                                                                                   <bullet> Weekly            additional increments can 
                                                                                                   <bullet> Monthly           be used if they are       
                                                                                                   <bullet> Yearly            registered on TSIN.COM and
                                                                                                   <bullet> {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: <e-mail           ``http:'', which          
                                                                                                    address.>.                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   
                                                                                                   <bullet> FIRM              classes provided. Three   
                                                                                                   <bullet> NON-FIRM          are pre-defined, while    
                                                                                                   <bullet> TTC               additional classes can be 
                                                                                                   <bullet> (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   
                                                                                                   <bullet> POINT__TO__POIN   types provided. Two are   
                                                                                                    T                         pre-defined, while        
                                                                                                   <bullet> NETWORK           additional types can be   
                                                                                                   <bullet> (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   
                                                                                                   <bullet> FIXED             windows provided. Two are 
                                                                                                   <bullet> SLIDING           pre-defined, while        
                                                                                                   <bullet> (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


</pre><script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script></body>
</html>