[Federal Register Volume 63, Number 195 (Thursday, October 8, 1998)]
[Rules and Regulations]
[Pages 54258-54306]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 98-26678]



[[Page 54257]]

_______________________________________________________________________

Part III





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. 195 / Thursday, October 8, 1998 / 
Rules and Regulations  

[[Page 54258]]



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 September 29, 1998.
AGENCY: Federal Energy Regulatory Commission.

ACTION: Order issuing revised OASIS standards and protocols document.
SUMMARY: In this order, the Federal Energy Regulatory Commission (the 
Commission): issues a revised OASIS Standards and Protocols Document 
(Version 1.3); grants a three-month extension of time for implementing 
Version 1.3 of the revised OASIS Standards and Protocols Document; and 
grants a two-month extension of time for implementing the Commission's 
requirements on unmasking source and sink information.

DATES: Version 1.3 of the OASIS Standards and Protocols Document 
becomes effective March 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
Paul Robb (Technical Information), Office of Electric Power Regulation, 
Federal Energy Regulatory Commission, 888 First Street, N.E., 
Washington, D.C. 20426, (202) 219-2702
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, DC 20426. In addition, 
the Commission Issuance Posting System (CIPS) provides access to the 
texts of formal documents issued by the Commission. CIPS can be 
accessed via Internet through FERC's Homepage (http://www.ferc.fed.us) 
using the CIPS Link or the Energy Information Online icon. The full 
text of this document will be available on CIPS in ASCII and 
WordPerfect 6.1 format. CIPS is also available through the Commission's 
electronic bulletin board service at no charge to the user and may be 
accessed using a personal computer with a modem by dialing (202) 208-
1397, if dialing locally, or 1-800-856-3920, if dialing long distance. 
To access CIPS, set your communications software to 19200, 14400, 
12000, 9600, 7200, 4800, 2400, or 1200 bps, full duplex, no parity, 8 
data bits and 1 stop bit. User assistance is available at (202) 208-
2474 or by E-Mail to [email protected].
    This document is also available through the Commission's Records 
and Information Management System (RIMS), an electronic storage and 
retrieval system of documents submitted to and issued by the Commission 
after November 16, 1981. Documents from November 1995 to the present 
can be viewed and printed. RIMS is available in the Public Reference 
Room or remotely via Internet through FERC's Homepage using the RIMS 
link or the Energy Information Online icon. User assistance is 
available at (202) 208-2222, or by E-Mail to [email protected].
    Finally, the complete text in WordPerfect format may be purchased 
from the Commission's copy contractor, RVJ International, Inc. RVJ 
International, Inc., is located in the Public Reference Room at 888 
First Street, N.E., Washington D.C. 20426.

Before Commissioners: James J. Hoecker, Chairman; Vicky A. Bailey, 
William L. Massey, Linda Breathitt, and Curt Hebert, Jr.

Order Issuing Revised OASIS Standards and Protocols Document, 
Granting Three-Month Extension of Time for Implementing Revised 
OASIS Standards and Protocols Document, and Granting Two-Month 
Extension of Time for Implementing the Commission's Requirements on 
Unmasking Source and Sink Information

    After consideration of suggested changes advanced by the OASIS How 
Working Group (How Group) and other interested persons, we are issuing 
a revised version (version 1.3) of the OASIS Standards and 
Communications Protocols document (referred to herein as the S&CP 
Document), consisting of revisions to version 1.2 of the S&CP Document 
issued by the Commission on June 18, 1998. Moreover, in response to a 
request from the How Group and the Commercial Practices Working Group 
(CPWG), we are granting a three-month extension, until March 1, 1999, 
for implementation of the requirements of version 1.3 and a two-month 
extension, also until March 1, 1999, for implementation of the 
Commission's requirements on the unmasking of source and sink 
information.

Background

    In an order issued on June 18, 1998,1 the Commission 
issued version 1.2 of the S&CP Document 2 and invited the 
How Group to file with the Commission a revised submittal, within 21 
days of the date of issuance of the June 18 Order that, ``to the 
greatest extent possible identifies all needed corrections to the S&CP 
Document.'' 3 The June 18 Order also requested that the How 
Group,

    \1\ Open Access Same-time Information System and Standards of 
Conduct, 63 FR 38,884 (July 20, 1998) 83 FERC para. 61,360 at 
62,466, (June 18 Order).
    \2\ 83 FERC at 62,466-67.
    \3\ 83 FERC at 62,452, n.13.
---------------------------------------------------------------------------

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

    \4\ Id.
---------------------------------------------------------------------------

    On July 15, 1998, the How Group filed a proposed version 1.3 of the 
S&CP Document, consisting of proposed clarifications and corrections to 
version 1.2 of the S&CP Document. These revisions included a proposal 
to add subsection 3.4(k) to the S&CP Document that would prescribe a 
standard method for posting organizational charts, job descriptions, 
and personnel names.
    On July 22, 1998, the Commission issued a notice of filing, 
inviting interested persons to file comments with the Commission on or 
before August 21, 1998.
    On August 11, 1998, the How Group and the CPWG jointly filed a 
letter requesting: (1) a delay in the date of implementation of the 
OASIS Phase 1-A S&CP Document (i.e., version 1.3) until March 1, 1999 
(a three-month delay); (2) a delay in the implementation date for the 
Commission's new rules on the unmasking of source and sink information 
(established in the June 18 Order) 5 until March 1, 1999 (a 
two-month delay); and (3) approval of the industry's Phase 1-A report 
on business practices, for implementation on March 1, 1999.
---------------------------------------------------------------------------

    \5\ 83 FERC at 62,456-67.

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

[[Page 54259]]

    On August 21, 1998, Southern Company Services, Inc., (Southern) 
6 filed comments supportive of the How Group's filing. 
However, Southern states that a few additional minor technical 
revisions need to be made to the document. Southern states that it 
discussed these additional proposed edits with the How Group at a How 
Group meeting held on July 23-24, 1998 and that, upon review, the How 
Group agrees with Southern that the additional technical revisions 
described in Southern's comments (and specified in an attachment to 
Southern's comments) need to be made.
---------------------------------------------------------------------------

    \6\ Southern's comments are filed on behalf of Alabama Power 
Company, Georgia Power Company, Gulf Power Company, Mississippi 
Power Company, and Savannah Electric and Power Company.
---------------------------------------------------------------------------

    Also on August 21, 1998, Enron Power Marketing, Inc. (EPMI) filed a 
motion to intervene raising no substantive issues.

Discussion

A. Issuance of the Revised S&CP Document (Version 1.3)
    As explained in the June 18 Order,7 the Commission has 
received a series of corrections and edits to the Phase 1-A S&CP 
Document. In the interests of issuing a revised document as free from 
errors as possible, we invited the How Group to carefully review this 
document and to file a revised document that, to the greatest extent 
possible, identified all needed corrections to the S&CP Document. The 
How Group complied with this request and submitted a revised Phase 1-A 
S&CP Document on July 15, 1998.
---------------------------------------------------------------------------

    \7\ 83 FERC at 62,452, n.13.
---------------------------------------------------------------------------

    However, Southern has identified three additional minor technical 
revisions that should be made to the document. These revisions: (1) add 
``START__TIME'' and ``STOP__TIME'' to the list of data elements under 
the ``INPUT'' and ``RESPONSE'' portions of several specified templates; 
8 (2) add ``STUDY'' and ``DISPLACED'' as permissible 
``STATUS'' values; 9 and (3) add further ``STATUS'' values 
in section 4.3.9.3.10
---------------------------------------------------------------------------

    \8\ Southern explains that this revision is needed because the 
narrative accompanying these sections references their inclusion. 
Southern Comments at 2.
    \9\ Southern explains that this revision is needed because 
section 4.3.9.2 provides that the values for ``STATUS'' and the 
processing of ``STATUS'' are to be the same as in section 4.3.7.2, 
which includes ``STUDY'' and ``DISPLACED'' as permissible ``STATUS'' 
values. Southern Comments at 2-3.
    \10\ Southern explains that this revision is needed to make the 
``STATUS'' values in this section equivalent to those in section 
4.3.7.3. Southern Comments at 3.
---------------------------------------------------------------------------

    We have reviewed the How Group's submittal along with Southern's 
comments (the only substantive comments filed in response to our notice 
of the How Group's filing) and find that this document improves upon 
version 1.2 of the S&CP Document. We, therefore, adopt version 1.3 of 
the S&CP Document,11 as modified herein.12
---------------------------------------------------------------------------

    \11\ Version 1.3 of the S&CP Document, without redline and 
strikeout fonts, is provided in Attachment 1. Attachment 2 to this 
order shows all the changes that we have made and direct to version 
1.2 of the S&CP Document in redline and strikeout fonts. We will 
publish Attachment 1 in the Federal Register. However, as redline 
and strikeout fonts do not show up in the Federal Register, we will 
not publish Attachment 2 in the Federal Register. It will, however, 
be made available on CIPS, RIMS, and in the Public Reference Room.
    \12\ We note that the document we are labeling as version 1.3 of 
the S&CP Document differs from the How Group's proposed version 1.3 
of the S&CP Document. The difference between the two documents is 
based on our inclusion of the revisions suggested by Southern's 
comments and a few nonsubstantive corrections (i.e., revised fonts 
and corrections to the table of contents).
---------------------------------------------------------------------------

B. Implementation Date for Version 1.3 of the S&CP Document
    The August 11, 1998 How Group/CPWG joint letter requested a delay 
in the implementation date of the OASIS Phase 1-A S&CP Document (i.e., 
version 1.3) until March 1, 1999 (a three-month delay). In support of 
this request, the How Group and CPWG argue that this delay will assure 
that the revised S&P Document will not need to be implemented at the 
start of the winter peak season. The How Group and CPWG argue that, by 
avoiding implementation of this requirement during the winter peak 
season, potential adverse effects on system reliability will be 
avoided. They argue that fears of disruption are not hypothetical, but 
are based on companies' experiences in implementing OASIS Phase 1 
requirements. The additional time will also allow customers and 
transmission providers time to complete modifications to ``backend'' 
systems to connect with OASIS servers.
    We agree. A three-month delay that minimizes potential start-up 
problems and avoids possible disruptions to reliability is appropriate. 
We will therefore modify the implementation date for version 1.3 of the 
S&CP Document to require implementation by March 1, 1999. Our 
determination in this regard is without prejudice to the pending 
requests for rehearing, on other grounds, of the June 18, 1998 Order. 
By addressing this request for a delayed implementation date, we intend 
no judgment on the merits of those pending requests for rehearing.
C. Implementation Date for New Rules on Unmasking Source and Sink 
Information
    The August 11, 1998 How Group/CPWG joint letter requested a delay 
in the implementation date for the Commission's new rules on unmasking 
of source and sink on the OASIS until March 1, 1999 (a two-month 
delay). In support of this request, the How Group and CPWG argue that 
having the same implementation date for the Commission's new rules on 
unmasking of source and sink information as for the revised S&CP 
Document will reduce the cost of implementation and will avoid the risk 
that the industry simultaneously will face the requirement to comply 
with the Commission's new rules on unmasking source and sink 
information and possible Year 2000 anomalies.
    We agree that a two-month delay is appropriate. We, therefore, will 
modify the implementation date for compliance with the Commission's new 
rules on unmasking source and sink information to require compliance 
with this requirement by March 1, 1999. Our determination in this 
regard is without prejudice to the pending requests for rehearing of 
the June 18, 1998 Order. By addressing this request for a delayed 
implementation date, we intend no judgment on the merits of those 
pending requests for rehearing.

The Commission Orders

    (A) Version 1.3 of the OASIS Phase 1-A S&CP Document (as shown on 
Attachment 1 to this order) is hereby adopted for use on and after 
March 1, 1999, as discussed in the body of this order.
    (B) The effective date for the requirements on unmasking source and 
sink information is hereby changed to March 1, 1999, as discussed in 
the body of this order.

    By the Commission. Commissioner Bailey concurred with a separate 
statement attached.
David P. Boergers,
Secretary.

[[Page 54260]]

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

ATTACHMENT 1--Federal Energy Regulatory Commission, Standards and 
Communication Protocols for Open Access Same-Time Information System 
(OASIS)

Version 1.3

September 29, 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  Linking of Ancillary Services to Transmission Services
    4.3  Template Descriptions
        4.3.1  Template Summary

[[Page 54261]]

        4.3.2  Query/Response of Posted Services Being Offered
            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.9.5  Seller to Reassign Service Rights to Another
             Customer (ancassign)
        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  Standard 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  Examples 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 Declined by Seller
            4.4.6.5  Negotiations Withdrawn by Customer
            4.4.6.6  Negotiations Superseded by Higher Priority
             Reservation
            4.5 Information Supported by Web Page
5. Performance Requirements
    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.1 Migration Requirements
Appendix A--Date 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 54262]]

    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 TSIPs so that User's web browsers 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 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. Browser Support: OASIS Nodes shall insure that Users running 
minimally either Netscape's Navigator version 4.0.x or Microsoft's 
Internet Explorer version 4.0.x browsers (or any other commercially 
or privately available browser supporting that set of capabilities 
common to both of these industry standard browsers) shall have a 
fully functional user interface based on the Interface Requirements 
defined in Section 4.
    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.

[[Page 54263]]

    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. 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 (case sensitive), 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.
    k. Organizational Charts: As required in 83 FERC 61,301, each 
Provider shall provide the company's organizational chart, job 
descriptions, and personnel names, using formats viewable and 
downloadable directly (i.e., without the use of external or third-
party plug-ins or application software) by the browsers listed in 
Section 2.4a.

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.

[[Page 54264]]

    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 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-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 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 an OASIS Node. 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'' (all 
upper case) 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) (case sensitive) 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 (case sensitive):
http://(OASIS Node name)/OASIS/(PRIMARY__PROVIDER__CODE)/data/(cgi 
script name)?(query variables)

Where:
    (cgi script name) is the OASIS Template name in lower case (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.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.htm|datadic.txt)

Where:

datadic.htm is the HTML version of the data element dictionary (case 
sensitive)
datadic.txt is the ASCII text version of the data element dictionary 
(case sensitive)


[[Page 54265]]


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

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 
Nodes, 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 Nodes. 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 Nodes 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 an OASIS Node. Each query/response Template 
accepts a set of user specified Query Variables and returns the 
appropriate information from data posted on the OASIS Node 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 an OASIS Node. 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 an OASIS Node:
    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 HTML screens implemented on OASIS Nodes, 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 an OASIS Node 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 an OASIS Node 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 Nodes 
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 requests. 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 Nodes 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 an OASIS Node 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. An OASIS Node shall support the 
specification of all Data Elements associated with a Template by

[[Page 54266]]

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.
    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 Node 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 Node 
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 an OASIS Node, 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 the OASIS Node , and the 
``response'' specifies the information returned to the User.

4.2.5.1  Input Requirements

    Input information is transferred to an OASIS Node 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 Nodes 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 Nodes 
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 an OASIS Node 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 Nodes 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 Node shall return an indication as to the 
success/failure of the requested action. The OASIS Node 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 Node 
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 Nodes 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 Nodes 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

[[Page 54267]]

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. Such multiple instances are 
documented in the Template definitions using an asterisk (*) after 
the query variable. When more than one instance of the Query 
Variable is specified in the query string, OASIS Nodes 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 asterisk (*).

4.2.6.5  Logical Operations

    OASIS Nodes 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 
Nodes 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 Nodes 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 Nodes 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--TIME 970201000000ES'' 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 (2) 
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.7  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 Nodes 
as part of the body of an HTTP message using the ``Content-length:'' 
HTTP header to define the length in bytes of the message body, and 
the ``Content-type: text/x-oasis-csv'' HTTP header to identify the 
data type associated with the message body. CSV formatted data 
consists of a fixed set of header records followed by a variable 
number of data records. Each record shall be separated by a carriage 
return plus line feed (denoted by the symbol  in all 
examples). The fields within a record shall be delimited by commas 
(,). All data within a CSV formatted message shall use printable 
ASCII characters with no other special embedded codes, with the 
exception of the special encoding requirements associated with text 
fields.

[[Page 54268]]

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 
Nodes 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 Node 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 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 
COLUMN__HEADERS record. The number of Data Records in the message is 
defined by the DATA__ROWS header record. The data values associated 
with each column Data Element are interpreted based on the Data 
Element type as defined in the Data Dictionary:
    a. Numeric Data Elements: All numeric Data Elements shall be 
represented by an ASCII string of numeric digits in base ten, plus 
the decimal point.
    b. Text Data Elements: Alphabetic and alphanumeric data elements 
shall be represented as ASCII strings and encoded using the 
following rules:
     Text strings that do not contain commas (,) or double 
quotes (``) shall be accepted both with and without being enclosed 
by double quotes.
     Text fields with commas (,) or double quotes (``) must 
be enclosed with double quotes. In addition double quotes within a 
text field shall be indicated by two double quotes (`` '').
     The Data Element field length specified in Data 
Dictionary does not include the additional double quotes necessary 
to encode text data.
    c. 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 CSV-formatted Response to a 
Template Input shall be indicated through the use of RECORD__STATUS 
and ERROR__MESSAGE Data Elements which are included in each data 
record (row) of the Response.
     If no error was encountered in an Input data record, 
the RECORD__STATUS Data Element in the corresponding Response record 
shall be returned with a value of 200 (success), and the 
ERROR__MESSAGE shall be blank.

[[Page 54269]]

     If any error is detected in processing an Input data 
record, it shall be indicated by a RECORD__STATUS Data Element value 
other than 200. The ERROR__MESSAGE shall be set to an appropriate 
text message to indicate the source of the error in that data 
record.
    The overall validity of each Template Query or Input shall be 
indicated in the CSV-formatted Response via the two REQUEST__STATUS 
and ERROR__MESSAGE header records (see section 4.2.7.3):
     If no errors were encountered in processing the User's 
Input data records, the REQUEST__STATUS shall be returned with the 
value of 200 (success), and the ERROR__MESSAGE shall be blank.
     If any errors were detected in the Template Input data 
records, the REQUEST__STATUS value shall 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 Node with a 
Provider. For all levels of access to OASIS information beyond 
simple read-only access, OASIS Nodes 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 Nodes shall maintain the following information for 
each Company:
    a. Company Code: 4 character code for primary transmission 
providers; 6 character code for eligible customers in accordance 
with NERC Tagging Information System (TIS) requirements shall be 
maintained for each Company.
    b. Default Contact: Unless specified for each individual user 
affiliated with the Company, default contact information consisting 
of a phone number, fax number, and e-mail address shall be 
maintained for each Company.
    c. Provider Affiliation: Each eligible Customer shall be 
obligated to identify to the OASIS TSIP any affiliation with a 
Transmission Provider whose ``home page'' is on that OASIS Node.
    d. Notification URL: For Companies using the URL notification 
mechanism for delivery of messages on each change of ancillary/
transmission reservation STATUS, each Company shall provide the IP 
host name and port number to be used in delivering notification 
messages. OASIS Nodes shall have the right to refuse support for 
notification to any IP ports other than port 80.

4.2.8.3  User Information

    With the exception of ``read-only'' (visitor) access, OASIS 
Nodes shall as a minimum provide a mechanism to identify Users of 
the Node with at least their Company. However, OASIS Nodes and 
Providers shall have the right to require full User identification 
even for visitor accounts.
    To support the required OASIS Template Data Elements, OASIS 
Nodes shall maintain the following information for each registered 
User:

 Company
 Name
 Phone
 Fax
 E-mail

    In the event no additional User identification/registration 
information is maintained by the OASIS Nodes, 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 Nodes have a clear and 
unambiguous representation of time associated with all information 
transferred to/from OASIS Nodes. For this reason, all Data Elements 
associated with time in OASIS Nodes 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 Nodes 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 Nodes 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 Nodes 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:00am 
on the first Sunday of April through 2:00 am 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 Nodes for conversion to

[[Page 54270]]

all other time zones. The input of start/stop times for 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 Node 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 Nodes 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 Nodes 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 Node sets the initial STATUS of the request to 
QUEUED. The Customer may set the STATUS__NOTIFICATION to indicate 
that the OASIS Node 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. 
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, INVALID, STUDY, COUNTEROFFER, 
ACCEPTED, REFUSED, SUPERSEDED, DECLINED, 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 COUNTEROFFER 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 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 Nodes 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 Nodes 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 Nodes 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''.
INVALID=assigned by TSIP or Provider indicating an invalid field in 
the request, such as improper POR, POD, source, sink, etc. (Final 
state).
RECEIVED=assigned by Provider or Seller to acknowledge QUEUED 
requests and indicate the service request is being evaluated, 
including for completing the required ancillary services.
STUDY=assigned by Provider or Seller to indicate some level of study 
is required or being performed to evaluate service request.
REFUSED=assigned by Provider or Seller to indicate service request 
has been denied due to availability of transmission capability. 
SELLER__COMMENTS should be used to communicate details for denial of 
service. (Final state).
COUNTEROFFER=assigned by Provider or Seller to indicate that a new 
OFFER__PRICE is being proposed.
REBID = assigned by Customer to indicate that a new BID__PRICE is 
being proposed.
SUPERSEDED = assigned by Provider or Seller when a request which has 
not yet been confirmed is displaced by another reservation request. 
(Final state).
ACCEPTED = assigned by Provider or Seller to indicate the service 
request at the designated OFFER__PRICE has been approved/accepted. 
If the reservation request was submitted PRECONFIRMED, the OASIS 
Node 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.
DECLINED = assigned by Provider or Seller to indicate that the 
BID__PRICE is unacceptable and that negotiations are terminated. 
SELLER__COMMENTS should be used to communicate reason for denial of 
service. (Final state).
CONFIRMED = assigned by Customer in response to Provider or Seller 
posting ``ACCEPTED'' status, to confirm service. Once a request has 
been ``CONFIRMED'', a transmission service reservation exists. 
(Final state, unless overridden by DISPLACED or ANNULLED state).

[[Page 54271]]

WITHDRAWN = assigned by Customer at any point in request evaluation 
to withdraw the request from any further action. (Final state).
DISPLACED = assigned by Provider or Seller when a ``CONFIRMED'' 
reservation from a Customer is displaced by a longer term 
reservation and the Customer has exercised right of first refusal 
(i.e. refused to match terms of new request). (Final state).
ANNULLED = assigned by Provider or Seller when, by mutual agreement 
with the Customer, a confirmed reservation is to be voided. (Final 
state).
RETRACTED = assigned by Provider or Seller when the Customer fails 
to confirm or withdraw the request within the required time period. 
(Final state).
    The following diagram can be used as a business process guideline; 
however, individual tariffs will dictate specific allowed actions 
between states.

BILLING CODE 6717-01-P

[[Page 54272]]

[GRAPHIC] [TIFF OMITTED] TR08OC98.000



BILLING CODE 6717-01-C

[[Page 54273]]

4.2.10.3  Dynamic Notification

    Customers may specify the delivery of dynamic notification 
messages on each change in STATUS of an ancillary or transmission 
service reservation. OASIS Nodes 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 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. This extension of dynamic notification is 
required only where the Transmission Provider has programmed its 
computer system for its own notification.

4.2.10.3.1  HTTP Notification

    OASIS Nodes 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. An OASIS 
Node 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 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'', an OASIS Node 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://oasistc.xyz.com:80
    The contents of the HTTP protocol notification message delivered 
by an OASIS Node 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 POST method 
request. In addition to the POST method HTTP header record, OASIS 
Nodes 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 Nodes 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 given an ASSIGNMENT__REF of 245 would be,

POST http://oasistc.xyz.com:80/cgi-bin/
status?DEAL__REF=8&REQUEST__REF=173 HTTP/1.0
Content-type: text/x-oasis-csv
Content-length: 
REQUEST__STATUS=200
TIME__STAMP=
VERSION=1.3
TEMPLATE=transstatus
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=ABC
PRIMARY__PROVIDER__DUNS=123456789
RETURN__TZ=
DATA__ROWS=1
COLUMN__HEADERS=CONTINUATION__FLAG, ASSIGNMENT__REF, . . .
N, 245, . . .

    In the event an error is encountered delivering the HTTP 
notification message to the target URL as indicated by a failure of 
the target system to respond, or return of HTTP response status of 
408, 500, 503, or 504, OASIS Nodes shall retry up to two more times, 
once every 5 minutes.

4.2.10.3.2  E-mail Notification

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

[[Page 54274]]

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 an OASIS Node. 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 an 
OASIS Node. 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 the OASIS Node (via the transsell or 
transassign templates) or by some other approved method. This 
reassignment information consists of the ASSIGNMENT__REF value 
assigned to the original reservation(s) and the time interval and 
capacity amount(s) being reassigned to the new reservation. These 
values are retained in the REASSIGNED__REF, REASSIGNED__START__TIME, 
REASSIGNED__STOP__TIME, and REASSIGNED__CAPACITY data elements.
    Sellers may identify their service offerings received from 
Customers through the Seller supplied value specified for the 
SALE__REF data element.
    Customers may track their purchase requests through the Customer 
supplied values specified for the DEAL__REF and REQUEST__REF data 
elements. Customers may also use POSTING__REF and SALE__REF in their 
purchase requests to refer back to posted offerings.

4.2.12  Linking of Ancillary Services to Transmission Services

    The requirements related to ancillary services are shown in 
transoffering (and updated using transupdate) using the 
ANC__SVC__REQ data element containing the following permitted 
values: SC:x; RV:x; RF:x; EI:x; SP:x; SU:x;

Where SC, RV, RF, EI, SP and SU are the ancillary services 1 through 
6 described in the Proforma Tariff,

 SC--Scheduling, system Control and dispatch
 RV--Reactive supply and Voltage control
 RF--Regulation and Frequency response
 EI--Energy Imbalance
 SP--SPinning reserve
 SU--SUpplemental reserve

and where x={M,R,O,U} means one of the following:

 Mandatory, which implies that the Primary Provider must 
provide the ancillary service
 Required, which implies that the ancillary service is 
required, but not necessarily from the Primary Provider
 Optional, which implies that the ancillary service is not 
necessarily required, but could be provided
 Unknown, which implies that the requirements for the 
ancillary service are not known at this time
    Ancillary services may be requested by a User from the Provider 
at the same time as transmission services are requested via the 
transrequest template, by entering the special codes into 
ANC__SVC__LINK to represent the Proforma ancillary services 1 
through 6 (or more) as follows:

SC:(AA); RV: (AA); RF: (AA[: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
--``SP'' to indicate that the Customer will self-provide the 
ancillary services, or
--``RQ'' to indicate that the Customer is asking the OASIS Node 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 
(ASSIGMNENT__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 
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.


[[Page 54275]]


``SC:(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 ``SANC'' 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'' from this seller. In this 
case the OASIS reservation number 8763 will be depleted 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:98
24));
 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 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.

--------------------------------------------------------------------------------------------------------------------------------------------------------
             Process area                                                 Process name                                              Template(s)
--------------------------------------------------------------------------------------------------------------------------------------------------------
4.3.2  Query/Response of Posted        Query/Response Transmission Capacity Offerings...................................  transoffering
 Services Being Offered.
                                       Query/Response Ancillary Service Offerings.......................................  ancoffering
4.3.3  Query/Response of Services      Query/Response Transmission Services.............................................  transserv
 Information.
                                       Query/Response Ancillary Services................................................  ancserv
4.3.4  Query/Response of Schedules     Query/Response Transmission Schedules............................................  schedule
 and Curtailments.
                                       Query/Response Curtailments......................................................  curtail
4.3.5  Query/Response of Lists of      Query/Response List of Sellers, Paths, PORs, PODs, Capacity Types, Ancillary       list
 Information.                           Service Types, Templates.
4.3.6  Query/Response of Audit Log...  Query/Response Audit Log.........................................................  auditlog
4.3.7  Purchase......................  Request Purchase of Transmission.................................................  transrequest
Transmission Services................  Services (Input).................................................................  ..............................
                                       Query/Response Status of Transmission Service Request............................  transstatus
                                       Seller Approves Purchase (Input).................................................  transsell
                                       Customer Confirm/Withdraw Purchase of Transmission Service (Input)...............  transcust
                                       Alternate POD/POR................................................................  transalt
                                       Seller Reassign Rights (Input)...................................................  transassign
4.3.8  Seller Posting of Transmission  Seller Post Transmission Service for Sale (Input)................................  transpost
 Service.
                                       Seller Modify (Remove) Transmission Service for Sale (Input).....................  transupdate
4.3.9  Purchase of Ancillary Service.  Request Purchase of Ancillary Service (Input)....................................  ancrequest
                                       Query/Response Status of Ancillary Service Request...............................  ancstatus
                                       Seller Approves Purchase of Ancillary Service (Input)............................  ancsell
                                       Customer Accept/Withdraw Purchase of Ancillary Service (Input)...................  anccust
                                       Seller Reassign Rights (Input)...................................................  ancassign
4.3.10  Seller Post Ancillary Service  Seller Post Ancillary Service (Input)............................................  ancpost
                                       Seller Modify (Remove) Ancillary Service for Sale (Input)........................  ancupdate
4.3.11  Informal Messages............  Post Want Ads (Input)............................................................  messagepost
                                       Query/Response Want Ads..........................................................  message
                                       Delete Want Ad (Input)...........................................................  messagedelete
                                       Personnel Transfers..............................................................  personnel
                                       Discretion.......................................................................  discretion
                                       Standards of Conduct.............................................................  stdconduct
--------------------------------------------------------------------------------------------------------------------------------------------------------


[[Page 54276]]

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 Nodes 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 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 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 required 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*
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__CURTAILMENT__PRIORITY
SELLER__NAME
SELLER__PHONE

[[Page 54277]]

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
SELLER__CODE
SELLER__DUNS
CONTROL__AREA
OFFER__START__TIME
OFFER__STOP__TIME
START__TIME
STOP__TIME
CAPACITY
SERVICE__INCREMENT
ANC__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__CURTAILMENT__PRIORITY, and OTHER__CURTAILMENT__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

[[Page 54278]]

SERVICE__INCREMENT
ANC__SERVICE__TYPE
CEILING__PRICE
PRICE__UNITS
SERVICE__DESCRIPTION
TARIFF__REFERENCE

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 Node 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*
SERVICE__INCREMENT*
TS__CLASS*
TS__TYPE*
TS__PERIOD*
START__TIME
STOP__TIME
TIME__OF__LAST__UPDATE
ASSIGNMENT__REF

2. Response

TIME__OF__LAST__UPDATE

[[Page 54279]]

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__CODE, PATH__NAME, POINT__OF__RECEIPT, 
POINT__OF__DELIVERY, SERVICE__INCREMENT, TS__CLASS, TS__TYPE, 
TS__PERIOD, TS__SUBCLASS, TS__WINDOW, NERC__CURTAILMENT__PRIORITY, 
OTHER__CURTAILMENT__PRIORITY, ANC__SERVICE__TYPE, CATEGORY, and 
TEMPLATE. 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)
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 service, which request different 
capacities (and optionally price) 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. Each segment of a profile is represented by the 
data elements CAPACITY, START__TIME, and STOP__TIME, which define 
the intervals

[[Page 54280]]

in time overwhich a non-zero MW demand is being requested. The 
initial segment of a profile is defined by the CAPACITY, START__TIME 
and STOP__TIME data elements specified in the first/only record 
submitted; subsequent segments are specified in continuation records 
each containing the appropriate CAPACITY, START__TIME and STOP__TIME 
values defining the segment. Provider's may optionally support price 
negotiation on segments of a profiled reservation request. In this 
case, the BID__PRICE data element is also included in each 
continuation record. If the BID__PRICE data element is not specified 
in the continuation records, the BID__PRICE specified in the first/
only record submitted will be applied to the entire reservation 
request.
    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__WINDOW
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
POINT__OF__DELIVERY
SOURCE
SINK
CAPACITY
SERVICE__INCREMENT
TS__CLASS
TS__TYPE
TS__PERIOD
TS__WINDOW
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. However, the SOURCE and SINK may 
be masked for User requests until Transmission Providers must make 
source and sink information available at the time the request status 
posting is updated to show that a transmission request is confirmed.
    Continuation records may be returned in association with a 
transmission reservation to convey information regarding: 1) sale or 
assignment of transmission rights on the secondary market 
(reassignments), 2) profiled requests, or 3) service over multiple 
paths. When a transmission reservation request is the result of a 
sale or assignment of transmission rights on the secondary market, 
the

[[Page 54281]]

identity of the original reservation, capacity, and time interval 
over which rights are assigned to the new reservation are defined by 
the data elements REASSIGNED__REF, REASSIGNED__CAPACITY, 
REASSIGNED__START__TIME, and REASSIGNED__STOP__TIME. These data 
elements will be returned in continuation records when more than one 
set of reassignment information is associated with a reservation. If 
the reservation has an associated profile (support for reservation 
profiles is at the discretion of the Provider), CAPACITY, 
START__TIME and STOP__TIME for the segments of the profile will be 
returned in continuation records. If the Provider supports 
negotiation of price on each segment of a profiled request, 
BID__PRICE and OFFER__PRICE will also be returned with CAPACITY, 
START__TIME and STOP__TIME. If the Provider supports reservations 
submitted on multiple paths, multiple PATH__NAMEs associated with 
the reservation would be returned in continuation records.
    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)
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
PRICE__UNITS
PRECONFIRMED
ANC__SVC__LINK
ANC__SVC__REQ
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, INVALID, STUDY, REBID, COUNTEROFFER, 
ACCEPTED, DECLINED, SUPERSEDED, REFUSED, CONFIRMED, WITHDRAWN, 
DISPLACED, ANNULLED, RETRACTED
STATUS__NOTIFICATION
STATUS__COMMENTS
TIME__QUEUED
RESPONSE__TIME__LIMIT
TIME__OF__LAST__UPDATE
PRIMARY__PROVIDER__COMMENTS

[[Page 54282]]

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.
    The following fields may be submitted in continuation records 
for the transsell Template to convey transmission rights from 
multiple original transmission reservations to this new reservation: 
REASSIGNED__REF, REASSIGNED__CAPACITY, REASSIGNED__START__TIME, and 
REASSIGNED__STOP__TIME. If the Provider/Seller supports the 
negotiation of price on individual segments of a profiled 
reservation request (support for reservation profiles is at the 
discretion of the Provider), OFFER__PRICE, START__TIME and 
STOP__TIME data elements may be submitted in continuation records to 
modify the Seller's offer price associated with the profile 
segment(s) corresponding to START__TIME and STOP__TIME. OFFER__PRICE 
associated with each segment of a profiled request must match the 
corresponding BID__PRICE for the reservation request's STATUS to be 
set to ACCEPTED.
    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
ASSIGNMENT__REF (Required)
START__TIME
STOP__TIME
OFFER__PRICE
STATUS=RECEIVED, INVALID, STUDY, COUNTEROFFER, ACCEPTED, REFUSED, 
SUPERSEDED, DECLINED, ANNULLED, RETRACTED, DISPLACED
STATUS__COMMENTS
ANC__SVC__LINK
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
START__TIME
STOP__TIME
OFFER__PRICE
STATUS=RECEIVED, INVALID, STUDY, COUNTEROFFER, ACCEPTED, REFUSED, 
SUPERSEDED, DECLINED, ANNULLED, RETRACTED, DISPLACED
STATUS__COMMENTS
ANC__SVC__LINK
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 before the reservation request's STATUS can be set to 
CONFIRMED.
    If the Provider/Seller supports the negotiation of price on 
individual segments of a profiled reservation request (support for 
reservation profiles is at the discretion of the Provider), 
BID__PRICE, START__TIME and STOP__TIME data elements may be 
submitted in continuation records to modify the Customer's bid price 
associated with the profile segment(s) corresponding to START__TIME 
and STOP__TIME. BID__PRICE associated with each segment of a 
profiled request must match the corresponding OFFER__PRICE for the 
reservation request's STATUS to be set to CONFIRMED.

Template: transcust

1. Input

CONTINUATION__FLAG

[[Page 54283]]

ASSIGNMENT__REF (Required)
START__TIME
STOP__TIME
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
START__TIME
STOP__TIME
REQUEST__REF
DEAL__REF
BID__PRICE
STATUS=REBID, CONFIRMED, WITHDRAWN
STATUS__COMMENTS
ANC__SVC__LINK
STATUS__NOTIFICATION
CUSTOMER__COMMENTS
ERROR__MESSAGE

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 Nodes 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)
OFFER__PRICE=$0
BID__PRICE=$0
CEILING__PRICE=$0
TS__CLASS=SECONDARY or other class allowed by the Provider
TS__TYPE=(value from TS__TYPE in reservation designated by 
REASSIGNED__REF)
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)
TS__CLASS
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)
PATH__NAME
POINT__OF__RECEIPT
POINT__OF__DELIVERY
SOURCE

[[Page 54284]]

SINK
PRECONFIRMED
CAPACITY (Capacity requested)
TS__CLASS
STATUS__NOTIFICATION
START__TIME
STOP__TIME
REQUEST__REF
DEAL__REF
REASSIGNED__REF (Assignment Reference for the Firm reservation being 
used for request)
CUSTOMER__COMMENTS
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 Node. 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__WINDOW
TS__SUBCLASS
START__TIME
STOP__TIME
OFFER__PRICE
ANC__SVC__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__WINDOW
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 
purchases to create a new service, if this capability is provided by 
the Transmission Services Information Provider:

[[Page 54285]]

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

[[Page 54286]]

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 request 
ancillary services that have been posted by a seller of those 
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. The same requirements exist for the 
use of STATUS__NOTIFICATION as for transrequest. Submitting 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 ancillary service, which request 
different capacities (and optionally price) 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. Each segment of a profile is represented by 
the data elements CAPACITY, START__TIME, and STOP__TIME, which 
define the intervals in time overwhich a non-zero MW demand is being 
requested. The initial segment of a profile is defined by the 
CAPACITY, START__TIME and STOP__TIME data elements specified in the 
first/only record submitted; subsequent segments are specified in 
continuation records each containing the appropriate CAPACITY, 
START__TIME and STOP__TIME values defining the segment. Provider's 
may optionally support price negotiation on segments of a profiled 
reservation request. In this case, the BID__PRICE data element is 
also included in each continuation record. If the BID__PRICE data 
element is not specified in the continuation records, the BID__PRICE 
specified in the first/only record submitted will be applied to the 
entire reservation request.
    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 
ancstatus Template to CONFIRMED when that request is ACCEPTED by the 
Seller.

Template: ancrequest

1. Input

CONTINUATION__FLAG
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 (acknowledgment)

RECORD__STATUS
CONTINUATION__FLAG
ASSIGNMENT__REF (assigned by TSIP)
SELLER__CODE
SELLER__DUNS
CONTROL__AREA
CAPACITY
SERVICE__INCREMENT
ANC__SERVICE__TYPE
STATUS__NOTIFICATION
START__TIME
STOP__TIME
BID__PRICE
PRECONFIRMED
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.
    Continuation records may be returned in association with a 
ancillary services reservation to convey information regarding: 1) 
sale or assignment of ancillary rights on the secondary market 
(reassignments), or 2) profiled requests. When an ancillary 
reservation request is the result of a sale or assignment of 
transmission or ancillary rights on the secondary market, the 
identity of the original reservation, capacity, and time interval 
over which rights are assigned to the new reservation are defined by 
the data elements REASSIGNED__REF, REASSIGNED__CAPACITY, 
REASSIGNED__START__TIME, and REASSIGNED__STOP__TIME. These data 
elements will be returned in continuation records when more than one 
set of reassignment information is associated with a reservation. If 
the reservation has an associated profile (support for reservation 
profiles is at the discretion of the Provider), CAPACITY, 
START__TIME and STOP__TIME for the segments of the profile will be 
returned in continuation records. If the Provider supports 
negotiation of price on each segment of a profiled request, 
BID__PRICE and OFFER__PRICE will also be returned with CAPACITY, 
START__TIME and STOP__TIME.

[[Page 54287]]

    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
NEGOTIATED__PRICE__FLAG
ASSIGNMENT__REF
REASSIGNED__REF
SALE__REF
REQUEST__REF
DEAL__REF
TIME__OF__LAST__UPDATE (only if TIME__OF__LAST__UPDATE is posted by 
record)

2. Response

CONTINUATION__FLAG
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
PRICE__UNITS
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, INVALID, RECEIVED, STUDY, REBID, COUNTEROFFER, 
ACCEPTED, REFUSED, CONFIRMED, WITHDRAWN, SUPERSEDED, DECLINED, 
ANNULLED, RETRACTED, DISPLACED
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
REASSIGNED__START__TIME
REASSIGNED__STOP__TIME

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.
    The following fields may be submitted in continuation records 
for the ancsell Template to convey ancillary rights from multiple 
original ancillary service reservations to this new reservation: 
REASSIGNED__REF, REASSIGNED__CAPACITY, REASSIGNED__START__TIME, and 
REASSIGNED__STOP__TIME. If the Provider/Seller supports the 
negotiation of price on individual segments of a profiled 
reservation request (support for reservation profiles is at the 
discretion of the Provider), OFFER__PRICE, START__TIME and 
STOP__TIME data elements may be submitted in continuation records to 
modify the Seller's offer price associated with the profile 
segment(s) corresponding to START__TIME and STOP__TIME. OFFER__PRICE 
associated with each segment of a profiled request must match the 
corresponding BID__PRICE for the reservation request's STATUS to be 
set to ACCEPTED.

[[Page 54288]]

    SELLER__ CODE and SELLER__ DUNS shall be determined from the 
registered connection used to input the request.

Template: ancsell

1. Input

CONTINUATION__ FLAG
ASSIGNMENT__REF (Required)
START__TIME
STOP__TIME
OFFER__PRICE
STATUS=INVALID, RECEIVED, STUDY, COUNTEROFFER, SUPERSEDED, ACCEPTED, 
REFUSED, DECLINED, ANNULLED, RETRACTED, DISPLACED
STATUS__COMMENTS
NEGOTIATED__PRICE__FLAG
RESPONSE__TIME__LIMIT
SELLER__COMMENTS
REASSIGNED__REF
REASSIGNED__CAPACITY
REASSIGNED__START__TIME
REASSIGNED__STOP__TIME

2. Response (acknowledgment)

RECORD__STATUS
CONTINUATION__FLAG
ASSIGNMENT__REF
START__TIME
STOP__TIME
OFFER__PRICE
STATUS=INVALID, RECEIVED, STUDY, COUNTEROFFER, SUPERSEDED, ACCEPTED, 
REFUSED, DECLINED, ANNULLED, RETRACTED, DISPLACED
STATUS__COMMENTS
NEGOTIATED__PRICE__FLAG
RESPONSE__TIME__LIMIT
SELLER__COMMENTS
REASSIGNED__REF
REASSIGNED__CAPACITY
REASSIGNED__START__TIME
REASSIGNED__STOP__TIME
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 reservation request's STATUS can be set to 
CONFIRMED. If the Provider/Seller supports the negotiation of price 
on individual segments of a profiled reservation request (support 
for reservation profiles is at the discretion of the Provider), 
BID__PRICE, START__TIME and STOP__TIME data elements may be 
submitted in continuation records to modify the Customer's bid price 
associated with the profile segment(s) corresponding to START__TIME 
and STOP__TIME. BID__PRICE associated with each segment of a 
profiled request must match the corresponding OFFER__PRICE for the 
reservation request's STATUS to 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

CONTINUATION__FLAG
ASSIGNMENT__REF (Required)
START__TIME
STOP__TIME
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
CONTINUATION__FLAG
ASSIGNMENT__REF
START__TIME
STOP__TIME
REQUEST__REF
DEAL__REF
BID__PRICE
STATUS= REBID, CONFIRMED, WITHDRAWN
STATUS__COMMENTS
STATUS__NOTIFICATION
CUSTOMER__COMMENTS
ERROR__MESSAGE

4.3.9.5  Seller to Reassign Service Rights to Another Customer 
(ancassign)

    Seller to Reassign Service Rights to Another Customer (Input) 
(ancassign) 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

[[Page 54289]]

that have occurred off the OASIS Node. Implementation of this 
template is optional until such time that a business case requiring 
the use of such a facility to selectively reassign ancillary 
services is clearly demonstrated.
    The TSIP shall assign a unique ASSIGNMENT__REF in the response 
(acknowledgment) and enter the status CONFIRMED as viewed in the 
ancstatus 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 ancassign 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: ancassign

1. Input

CONTINUATION__FLAG
CUSTOMER__CODE
CUSTOMER__DUNS
CONTROL__AREA
CAPACITY
SERVICE__INCREMENT
ANC__SERVICE__TYPE
START__TIME
STOP__TIME
OFFER__PRICE
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
CONTROL__AREA
CAPACITY (Total capacity being reassigned)
SERVICE__INCREMENT
ANC__SERVICE__TYPE
START__TIME
STOP__TIME
OFFER__PRICE
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.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
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

[[Page 54290]]

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

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

[[Page 54291]]

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

4.3.11.4 Personnel Transfers (personnel)

    The personnel template is used to indicate when personnel are 
transferred between the merchant function and the Transmission 
Provider function as required by FERC Statutes and Regulations 
(37.4(b)(2)) .

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

4.3.11.5  Discretion (discretion)

    The discretion template is used to describe the circumstances 
when discretion was exercised in applying terms of the tariff, as 
described in the FERC Statutes and Regulations (37.4(b)(5)(iii)).

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)

    The stdconduct template indicates when information is disclosed 
in a manner contrary to the standards of conduct, as described in 
the FERC Statutes and Regulations (37.4(b)(4)(ii)).

Template: stdconduct

1. Query

START__TIME__POSTED

[[Page 54292]]

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.3.
    The request is in the form of a URL query string and the 
response is a ASCII delimited file.

1. Query

    http://(OASIS Node name)/OASIS/aaa/data/transoffering? 
ver=1.2&templ=transoffering& fmt=data&pprov=AAAA 
&pprovduns=123456789& path=W/AAA/ABC// &seller=WXYZAA 
&sellerduns=987654321& POR=aaa& POD=bbb& servincre=hourly& 
TSCLASS1=firm &TSCLASS2=non-
firm&tz=PD&stime=19960410080000PD&sptime= 19960410150000PD
2. Response Data
REQUEST-STATUS=200 (Successful)
TIME__STAMP=19960409113526PD
VERSION=1.35
TEMPLATE=transoffering
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AAAA
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=14
COLUMN__HEADERS=TIME__OF__LAST__UPDATE, SELLER__CODE, SELLER__DUNS, 
PATH__NAME, POINT__OF__ RECEIPT, POINT__OF__DELIVERY, 
INTERFACE__TYPE, OFFER__START__TIME, OFFER__STOP__TIME, START__TIME, 
STOP__TIME, CAPACITY, SERVICE__INCREMENT, TS__CLASS, TS__TYPE, 
TS__PERIOD, TS__SUBCLASS, SALE__REF, POSTING__REF, CEILING__PRICE, 
OFFER__PRICE, PRICE__UNITS, SERVICE__DESCRIPTION, SELLER__NAME, 
SELLER__PHONE, SELLER__FAX, SELLER-EMAIL, SELLER__COMMENTS
19960409030000PD, WXYZ, 987654321, W/AAA/ABC//, N/A, N/A, E, 
19960402080000PD, 19960410080000PD, 199604100 80000PD, 
19960410090000PD, 300, HOURLY, FIRM, POINT__TO__POINT, OFF__PEAK, N/
A, N/A, A001, 1.50, 1.35, MW, N/A, N/A, N/A, N/A, N/A, 10% 
DISCOUNT
19960409030000PD, WXYZ, 987654321, W/AAA/ABC//, N/A, N/A, E, 
19960402080000PD, 19960410080000PD, 199604100 80000PD, 
19960410090000PD, 300, HOURLY, NON-FIRM, POINT__TO__POINT, 
OFF__PEAK, N/A, N/A, A001, 1.50, 1.35, MW, N/A, N/A, N/A, N/A, N/A, 
10% DISCOUNT
19960409030000PD, WXYZ, 987654321, W/AAA/ABC//, N/A, N/A, E, 
19960402080000PD, 19960410080000PD, 199604100 90000PD, 
1996041010000PD, 300, HOURLY, FIRM, POINT__TO__POINT, OFF__PEAK, N/
A, N/A, A001, 1.50, 1.35, MW, N/A, N/A, N/A, N/A, N/A, 10% 
DISCOUNT
19960409030000PD, WXYZ, 987654321, W/AAA/ABC//, N/A, N/A, E, 
19960402080000PD, 19960410080000PD, 199604100 90000PD, 
19960410100000PD, 300, HOURLY, NON-FIRM, POINT__TO__POINT, 
OFF__PEAK, N/A, N/A, A001, 1.50, 1.35, MW, N/A, N/A, N/A, N/A, N/A, 
10% DISCOUNT
19960409030000PD, WXYZ, 987654321, W/AAA/ABC//, N/A, N/A, E, 
19960402080000PD, 19960410080000PD, 199604101 00000PD, 
19960410110000PD, 300, HOURLY, FIRM, POINT__TO__POINT, OFF__PEAK, N/
A, N/A, A001, 1.50, 1.35, MW, N/A, N/A, N/A, N/A, N/A, 10% 
DISCOUNT
19960409030000PD, WXYZ, 987654321, W/AAA/ABC//, N/A, N/A, E, 
19960402080000PD, 19960410080000PD, 199604101 00000PD, 
19960410110000PD, 300, HOURLY, NON-FIRM, POINT__TO__POINT, 
OFF__PEAK, N/A, N/A, A001, 1.50, 1.35, MW, N/A, N/A, N/A, N/A, N/A, 
10% DISCOUNT
19960409030000PD, WXYZ, 987654321, W/AAA/ABC//, N/A, N/A, E, 
19960402080000PD, 19960410080000PD, 199604101 10000PD, 
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, N/A, 10% 
DISCOUNT
19960409030000PD, WXYZ, 987654321, W/AAA/ABC//, N/A, N/A, E, 
19960402080000PD, 19960410080000PD, 199604101 10000PD, 
19960410120000PD, 300, HOURLY, NON-FIRM, POINT__TO__POINT, 
OFF__PEAK, N/A, N/A, A001, 1.50, 1.35, MW, N/A, N/A, N/A, N/A, N/A, 
10% DISCOUNT
. . .
. . .
. . .
19960409030000PD, WXYZ, 987654321, W/AAA/ABC//, N/A, N/A, E, 
19960402080000PD, 19960410080000PD, 199604101 40000PD, 
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
19960409030000PD, WXYZ, 987654321, W/AAA/ABC//, N/A, N/A, E, 
19960402080000PD, 19960410080000PD, 199604101 40000PD, 
19960410150000PD, 300, HOURLY, NON-FIRM, POINT__TO__POINT, 
OFF__PEAK, N/A, N/A, A001, 1.50, 1.35, MW, N/A, N/A, N/A, N/A, N/A, 
10% DISCOUNT

4.4.2  File Example for Hourly Schedule Data

    This example shows a request for the hourly schedule data from 
Primary Provider, aaa, related to the seller, wxyz, for the period 
10 a.m. to 3 p.m. on April 10, 1996.
    There are two identical requests examples using two slightly 
different methods. The first request is using a HTTP URL request 
string through an HTML GET method. The second request is a similar 
example using fetch__http from a file using a POST method.

1. Query

URL Request (HTTP method=GET)

http://(OASIS Node name)/OASIS/aaa/data/schedule? ver=1.0& 
pprov=AAAA& templ=schedule& fmt=data &pprovduns=123456789 &path=W/
AAA/ABC//& seller=WXYZ &por=BBB &pod=CCC& tz=PD& 
stime=19960410100000PD& sptime=19960410150000PD

[[Page 54293]]

URL Request (HTTP method=POST)

$ fetch__ http http://(OASIS Node name)/OASIS/aaa/data/OASISdata -f 
c:/OASIS/wxyz/upload/in-file.txt
Where in-file.txt contains the following:
ver=1.0& pprov=AAAA& templ=schedule& fmt=data &pprovduns=123456789 
&path=W/AAA/ABC//& seller=WXYZ &por=BBB &pod=CCC& tz=PD& 
stime=19960410100000PD& sptime=19960410150000PD

2. Response Data

REQUEST-STATUS=200
TIME__STAMP=19960410114702PD
VERSION=1.3
TEMPLATE=schedule
OUTPUT__FORMAT=DATA 
PRIMARY__PROVIDER__CODE=AAAA
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=5
COLUMN__ HEADERS=TIME__ OF__ LAST__ UPDATE, SELLER__ CODE, SELLER__ 
DUNS, PATH__ NAME,
POINT__ OF__ RECEIPT, POINT__ OF__ DELIVERY, CUSTOMER__ CODE, 
CUSTOMER__ DUNS,
AFFILIATE__ FLAG, START__ TIME, STOP__ TIME, CAPACITY, CAPACITY__ 
SCHEDULED, SERVICE__ INCREMENT,
TS__CLASS, TS__TYPE, TS__PERIOD, TS__SUBCLASS, 
ASSIGNMENT__REF
19960409030000pd, wxyz, 0987654321, W/AAA/ABC//, BBB, CCC, WXYZAA, 
0987654322, Y,
19960410100000PD, 19960410110000PD, 300, 300, HOURLY, FIRM, 
POINT__TO__ POINT, OFF__ PEAK, N/A, 856743
. . . 
. . . 
19960409030000pd, wxyz, 0987654321, W/AAA/ABC//, BBB, CCC, WXYZAA, 
0987654322, Y,
19960410130000PD, 19960410140000PD, 300, 300, HOURLY, FIRM, 
POINT__TO__ POINT, OFF__ PEAK, N/A, 856743
19960409030000pd, wxyz, 0987654321, W/AAA/ABC//, BBB, CCC, WXYZAA, 
0987654322, Y,
19960410140000PD, 19960410150000PD, 300, 300, HOURLY, FIRM, 
POINT__TO__ POINT, OFF__ PEAK, N/A, 856743

4.4.3  Customer Posting a Transmission Service Offering

    This example shows how a Customer would post for sale the 
transmission service that was purchased 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.3
TEMPLATE=transpost
OUTPUT__FORMAT=DATA 
PRIMARY__PROVIDER__CODE=AAAA
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=1
COLUMN__HEADERS=PATH__NAME, POINT__OF__RECEIPT, POINT__OF__DELIVERY, 
INTERFACE__TYPE,
CAPACITY, SERVICE__INCREMENT, TS__CLASS, TS__TYPE, TS__PERIOD, 
TS__SUBCLASS, START__TIME,
STOP__TIME, OFFER__START__TIME, OFFER__STOP__TIME, SALE__REF, 
OFFER__PRICE,
SERVICE__DESCRIPTION, SELLER__COMMENTPF
WXYZ, 987654321, W/AAA/ABC//, N/A, N/A, E, 150, HOURLY, FIRM, 
POINT__TO__ POINT, OFF__ PEAK, N/A, 19960402080000PD, 
19960410080000PD, 19960410080000PD, 19960410150000PD, A123,.90,N/A, 
``As Joe said, ````It is a good buy''''''
FETCH__HTTP Command to send posting
$ fetch__ http http://(OASIS Node name)/OASIS/abcd/data/transrequest 
-f c:/OASIS/abcd/upload/post.txt

2. Response Data

REQUEST-STATUS=200  (Successful)
TIME__STAMP=19960409113526PD 
VERSION=1.3
TEMPLATE=transpost
OUTPUT__FORMAT=DATA 
PRIMARY__PROVIDER__CODE=AAAA
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=1
COLUMN__HEADERS=RECORD__STATUS, PATH__NAME, POINT__OF__RECEIPT, 
POINT__OF__DELIVERY,
INTERFACE__TYPE, CAPACITY, SERVICE__INCREMENT, TS__CLASS, TS__TYPE, 
TS__PERIOD, TS__SUBCLASS,
START__TIME, STOP__TIME, OFFER__START__TIME, OFFER__STOP__TIME, 
SALE__REF, OFFER__PRICE,
SERVICE__DESCRIPTION, SELLER__COMMENTS, ERROR__MESSAGE
200, WXYZ, 987654321, W/AAA/ABC//, N/A, N/A, E, 150, HOURLY, FIRM, 
POINT__TO__POINT, OFF__PEAK, N/A,
19960402080000PD, 19960410080000PD, 19960410080000PD, 
19960410150000PD, A123, .90, N/A, ``As Joe said, ````It is a good 
buy'''''', No Error

4.4.4  Example of Re-aggregating Purchasing Services Using Reassignment

    The following examples do not show the complete Template 
information, but only show those elements of the Template of 
interest to the example.
    a. Customer #1, ``BestE'' requests the purchase of 150 MW Firm 
ATC for 8 a.m. to 5 p.m. for $1.00 from a Primary Provider 
(transrequest).

TEMPLATE=transrequest
CUSTOMER__CODE=BestE
CAPACITY=150
TS__CLASS=``FIRM''
START__TIME=``1996050708000000PD''
STOP__TIME=``1996050717000000PD''
BID__PRICE=``$1.00''

    The Information Provider assigns ASSIGNMENT__REF = 5000 on 
acknowledgment.
    b. Customer #1 purchases 120 MW ATC Non-firm for 3 p.m. to 9 
p.m. for $.90 (transrequest). The Information Provider assigns the 
ASSIGNMENT__REF=5001 when the request for purchase is made and is 
shown in the acknowledgment.

TEMPLATE=``transrequest''
CUSTOMER__CODE=``BestE''

[[Page 54294]]

CAPACITY=120
TS__CLASS=``NON-FIRM''
START__TIME=``1996050715000000PD''
STOP__TIME=``1996050721000000PD''
BID__PRICE=``$1.05''

    c. Customer #1 becomes Seller #1 and post the Transmission 
service of 100 MW ATC Non-firm capacity from 8 a.m. to 9 p.m. for 
resale at $.90/MW-hour.

TEMPLATE=``transpost''
SELLER__CODE=``BestE''
CAPACITY=100
TS__CLASS=``NON-FIRM''
START__TIME=``1996050708000000PD''
STOP__TIME=``1996050721000000PD''
SALE__REF=``BEST100''
OFFER__PRICE=.90
SELLER__COMMENTS=``aggregating two previous purchases''

    d. Customer #2 then requests purchase of 100 MW Non-firm from 
Reseller #1 from 8 a.m. to 6 p.m. for $0.90/MW-hour (transrequest).

TEMPLATE=``transrequest''
CUSTOMER__CODE=``Whlsle''
SELLER__CODE=``BestE''
CAPACITY=100
TS__CLASS=``NON-FIRM''
START__TIME=``1996050708000000PD''
STOP__TIME=``1996050721000000PD''
SALE__REF=``BEST100''
DEAL__REF=``WPC100''
BID__PRICE=.90
CUSTOMER__COMMENTS=``Only need service until 6 p.m.''

    The Information Provider provides the ASSIGNMENT__REF=5002 for 
this transaction.
    e. Seller informs the Information Provider of the reassignment 
of the previous transmission rights when the seller accepts the 
customer purchase request (transsell).

TEMPLATE=``transsell''
CUSTOMER__CODE=``Whlsle''
SELLER__CODE=``BestE''
ASSIGNMENT__REF=5002
STATUS=``Accepted''
REASSIGNED__REF1=5000
REASSIGNED__CAPACITY1=100
REASSIGNED__START__TIME1 = ``199605070800PD''
REASSIGNED__STOP__TIME1 = ``199605071700PD''
REASSIGNED__REF2=5001
REASSIGNED__CAPACITY2=100
REASSIGNED__START__TIME2 = ``199605071700PD''
REASSIGNED__STOP__TIME2 = ``199605071800PD''

4.4.5  File Examples of the Use of Continuation Records

a. Basic Continuation Records

    The first example of the use of Continuation Records is for the 
transrequest Template submitted by a Seller for purchase of a 
transmission reservation spanning 16 hours from 06:00 to 22:00 with 
``ramped'' demand at beginning and end of time period. Two 
additional reservations appear prior to and following the profile to 
demonstrate the handling of ASSIGNMENT__REF by the OASIS Node.
    Only the following fields may be redefined in a continuation 
record for the transrequest Template: CAPACITY, START__TIME, 
STOP__TIME. Specification of any values corresponding to 
COLUMN__HEADERs other than CAPACITY, START__TIME, and STOP__TIME 
will be ignored, however commas must be included to properly align 
the CAPACITY, START__TIME and STOP__TIME fields.

Input:

VERSION=1.3
TEMPLATE=transrequest
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AEP
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=7
COLUMN__HEADERS = CONTINUATION__FLAG, SELLER__CODE, SELLER__DUNS, 
PATH__NAME, POINT__OF__RECEIPT, POINT__OF__DELIVERY, SOURCE, SINK, 
CAPACITY, SERVICE__INCREMENT, TS__CLASS, TS__TYPE, TS__PERIOD, 
TS__SUBCLASS, STATUS__NOTIFICATION, START__TIME, STOP__TIME, 
BID__PRICE, PRECONFIRMED, ANC__SVC__LINK, POSTING__REF, SALE__REF, 
REQUEST__REF, DEAL__REF, CUSTOMER__COMMENTS
N, AEP, 123456789, ABC/XY, CE, MECS, , , 35, DAILY, FIRM, 
POINT__TO__POINT, OFF__PEAK, N/A,, pub/AEP/incoming, 
19970423000000ES, 19970424000000ES, 24.50, 
Y,SC:(cust:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123); 
SP:(custR234); SU:(cust:R345), P0123 , S123, R765, D123, Standard 
daily reservation
N, AEP, 123456789, ABC/XY, CE, AMPO, , , 5, HOURLY, NON-FIRM, 
POINT__TO__POINT, OFF__PEAK, N/A, pub/AEP/incoming, 
19970423060000ES, 19970423070000ES, 2.50, 
Y,SC:(cust:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123); 
SP:(custR234); SU:(cust:R345), P0123 , S123, R765, D123, First piece 
of profile spanning 5 records
Y, , , , , , , , 10, , , , , , , 19970423070000ES, 19970423080000ES, 
, , , , , , , ,Second piece
Y, , , , , , , , 15, , , , , , , 19970423080000ES, 19970423200000ES, 
, , , , , , , ,Third piece
Y, , , , , , , , 10, , , , , , , 19970423200000ES, 19970423210000ES, 
, , , , , , , ,Fourth piece
Y, , , , , , , , 5, , , , , , , 19970423210000ES, 19970423220000ES, 
, , , , , , , ,Fifth piece
N, AEP, 123456789, ABC/XY, CE, MECS, , , 20, HOURLY, FIRM, 
POINT__TO__POINT, OFF__PEAK, N/A, pub/AEP/incoming, 
19970423040000ES, 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

Response:

REQUEST__STATUS=200

[[Page 54295]]

TIME__STAMP=19970422160523ES
TEMPLATE=transrequest
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AEP
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=7
COLUMN__HEADERS=RECORD__STATUS, CONTINUATION__FLAG, SELLER__CODE, 
SELLER__DUNS,
PATH__NAME, POINT__OF__RECEIPT, POINT__OF__DELIVERY, SOURCE, SINK, 
CAPACITY,
SERVICE__INCREMENT, TS__CLASS, TS__TYPE, TS__PERIOD, TS__SUBCLASS, 
STATUS__NOTIFICATION,
START__TIME, STOP__TIME, BID__PRICE, PRECONFIRMED, ANC__SVC__LINK, 
POSTING__REF, SALE__REF,
REQUEST__REF, DEAL__REF, CUSTOMER__COMMENTS, ERROR__MESSAGE
200, N, AEP, 123456789, ABC/XY, CE, MECS, , , 35, DAILY, FIRM, 
POINT__TO__POINT, OFF__PEAK, N/A, pub/AEP/incoming, 
19970423000000ES, 19970424000000ES, 24.50, 
Y,SC:(cust:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123); 
SP:(custR234); SU:(cust:R345), P0123, S123, R765, D123, Standard 
daily reservation, No error
200, N, AEP, 123456789, ABC/XY, CE, AMPO, , , 5, HOURLY, NON-FIRM, 
POINT__TO__POINT, OFF__PEAK, N/A, pub/AEP/incoming, 
19970423060000ES, 19970423070000ES, 2.50, 
Y,SC:(cust:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123); 
SP:(custR234); SU:(cust:R345), P0123, S123, R765, D123, First piece 
of profile spanning 5 records, No error
200, Y, , , , , , , , 10, , , , , , , 19970423070000ES, 
19970423080000ES, , , , , , , , , Second piece, No error
200, Y, , , , , , , , 15, , , , , , , 19970423080000ES, 
19970423200000ES, , , , , , , , , Third piece, No error
200, Y, , , , , , , , 10, , , , , , , 19970423200000ES, 
19970423210000ES, , , , , , , , , Fourth piece, No error
200, Y, , , , , , , , 5, , , , , , , 19970423210000ES, 
19970423220000ES, , , , , , , , , Fifth piece, No error
200, N, AEP, 123456789, ABC/XY, CE, MECS, , , 20, HOURLY, FIRM, 
POINT__TO__POINT, OFF__PEAK, N/A, pub/AEP/incoming, 
19970423040000ES, 19970423160000ES, 
2.00,Y,SC:(cust:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123); 
SP:(custR234); SU:(cust:R345), P0123, S123, R765, D123, Standard 
hourly reservation after profiled reservation, No error

b. Submission of Reassignment Information--Case 1:

    In the prior example, a reservation request was submitted to 
``Rseler'' for 20MW of Hourly Non-firm service from 04:00 to 16:00. 
Assume that Rseler has previously reserved service for the CE-VP 
path for Daily Firm in amount of 50 MW on 4/23 under 
ASSIGNMENT__REF=7019, and Hourly Non-Firm in amount of 10 MW from 
08:00 to 20:00 on 4/23 under ASSIGNMENT__REF=7880. Rseler must 
designate which transmission service rights are to be reassigned to 
Cust to satisfy the 20MW from 04:00 to 16:00. This reassignment 
information is conveyed by Rseler using the transsell Template when 
the reservation request is ACCEPTED. At the SELLER's discretion, 
rights are assigned from the Non-firm reservation first 
(ASSIGNMENT__REF=7880) with the balance taken up by the Firm 
reservation (ASSIGNMENT__REF=7019).
    The only fields allowed in ``continuation'' records for 
transsell Template are REASSIGNED__REF, REASSIGNED__CAPACITY, 
REASSIGNED__START__TIME , and REASSIGNED__STOP__TIME. Price may not 
be negotiated for each ``segment'' in a capacity profile.

Input:

VERSION=1.3
TEMPLATE=transsell
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AEP
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=3
COLUMN__HEADERS=CONTINUATION__FLAG, ASSIGNMENT__REF, OFFER__PRICE, 
STATUS,
STATUS__COMMENTS, ANC__SVC__LINK, SELLER__COMMENTS, REASSIGNED__REF,
REASSIGNED__CAPACITY, 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
Y, , , , , , , 7880, 10, 19970423080000ES, 19970423160000ES
Y, , , , , , , 7019, 10, 19970423080000ES, 19970423160000ES

Response:

VERSION=1.3
TEMPLATE=transsell
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AEP
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=3
COLUMN__HEADERS=RECORD__STATUS, CONTINUATION__FLAG, ASSIGNMENT__REF, 
OFFER__PRICE,
STATUS, STATUS__COMMENTS, ANC__SVC__LINK, SELLER__COMMENTS, 
REASSIGNED__REF,
REASSIGNED__CAPACITY, REASSIGNED__START__TIME, 
REASSIGNED__STOP__TIME, ERROR__MESSAGE
200, N, 8236, 2.00, ACCEPTED, Status comments 
here,SC:(cust:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123);
SP:(cust:R234); SU:(cust:R345), Seller comments here, 7019, 20, 
19970423040000ES, 19970423080000ES,
200, Y, , , , , , , 7880, 10, 19970423080000ES, 
19970423160000ES,
200, Y, , , , , , , 7019, 10, 19970423080000ES, 
19970423160000ES,

c. Submission of Reassignment Information--Case 2:

    Primary provider, AEP, is notified of a sale/assignment of 
transmission service rights 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.3
TEMPLATE=transassign

[[Page 54296]]

OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AEP
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=2
COLUMN__HEADERS=CONTINUATION__FLAG, CUSTOMER__CODE, CUSTOMER__DUNS, 
PATH__NAME,
POINT__OF__RECEIPT, POINT__OF__DELIVERY, SOURCE, SINK, CAPACITY, 
SERVICE__INCREMENT, TS__CLASS,
TS__TYPE, TS__PERIOD, TS__SUBCLASS, START__TIME, STOP__TIME, 
OFFER__PRICE, SALE__REF, POSTING__NAME,
REASSIGNED__REF, REASSIGNED__CAPACITY, REASSIGNED__START__TIME, 
REASSIGNED__STOP__TIME,
SELLER__COMMENTS
N, Resler, 456123789, Cust, 987654321, , CE, VP, , , 10, HOURLY, 
NON-FIRM, POINT__TO__POINT, OFF__PEAK, N/A, 19970423000000ES, 
19970423060000ES, 2.00, Joe Smith, Jane Doe , N, 19970422121354ES, , 
7019, 10, 19970423000000ES, 19970423060000ES, Seller comments go 
here
Y, , , , , , , , , , 10, , , , , , 19970423220000ES, 
19970424000000ES, , , , , , , 7019, 10, 19970423220000ES, 
19970424000000ES 

Response:

REQUEST__STATUS=200
TIME__STAMP=19970422144520ES
VERSION=1.3
TEMPLATE=transassign
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AEP
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=2
COLUMN__HEADERS=RECORD__STATUS, CONTINUATION__FLAG, ASSIGNMENT__REF, 
SELLER__CODE, SELLER__DUNS, CUSTOMER__CODE, CUSTOMER__DUNS, 
AFFILIATE__FLAG, PATH__NAME, POINT__OF__RECEIPT, 
POINT__OF__DELIVERY, SOURCE, SINK, CAPACITY, SERVICE__INCREMENT, 
TS__CLASS, TS__TYPE, TS__PERIOD, TS__SUBCLASS, START__TIME, 
STOP__TIME, OFFER__PRICE, SELLER__NAME, CUSTOMER__NAME, 
TIME__QUEUED, SALE__REF, REASSIGNED__REF, REASSIGNED__CAPACITY, 
REASSIGNED__START__TIME , REASSIGNED__STOP__TIME , SELLER__COMMENTS, 
ERROR__MESSAGE 200, N, 8207, Rseler, 456123789, Cust, 
987654321, N, , CE, VP, , , 10, HOURLY, FIRM, POINT__TO__POINT, 
OFF__PEAK, N/A, 19970423000000ES, 19970423060000ES, 2.00, Joe Smith, 
Jane Doe , 19970422121354ES, , 7019, 10, 19970423000000ES, 
19970423060000ES, Seller comments go here,
200, Y, , , , , , , , , , , , 10, , , , , , 19970423220000ES, 
19970424000000ES, , , , , , 7019, 10, 19970423220000ES, 
19970424000000ES,,

d. Query of Transmission Reservation Status:

    The following typical response to a transstatus query might be 
delivered for 4/23 based on prior examples. Note that the only 
fields returned in ``continuation'' records are, CAPACITY, 
START__TIME , STOP__TIME , REASSIGNED__REF, REASSIGNED__CAPACITY, 
REASSIGNED__START__TIME , and REASSIGNED__STOP__TIME (price fields 
are debatable).

Input:



Response:

REQUEST__STATUS=200
TIME__STAMP=19970423040523ES
TEMPLATE=transstatus
OUTPUT__FORMAT=DATA
PRIMARY__PROVIDER__CODE=AEP
PRIMARY__PROVIDER__DUNS=123456789
DATA__ROWS=11
COLUMN__HEADERS= CONTINUATION__FLAG, ASSIGNMENT__REF, SELLER__CODE, 
SELLER__DUNS, CUSTOMER__CODE, CUSTOMER__DUNS, AFFILIATE__FLAG, 
PATH__NAME, POINT__OF__RECEIPT, POINT__OF__DELIVERY, SOURCE, SINK, 
CAPACITY, SERVICE__INCREMENT, TS__CLASS, TS__TYPE, TS__PERIOD,
TS__SUBCLASS, START__TIME , STOP__TIME, CEILING__PRICE, 
OFFER__PRICE, BID__PRICE, PRECONFIRMED, ANC__SVC__LINK, 
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__TIME5
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, CONFIRMED, , 
19970422121354ES, , TP Comments, Seller comments go here, Customer 
comments, Joe Smith, (888)-123-4567, (888)-123-1231, [email protected], 
Jane Doe, (999)-123-4567, (999)-123-8823, , 7019, 10, 
19970423000000ES, 19970423060000ES 
Y, , , , , , , , , , , , ,10, , , , , , 19970423220000ES, 
19970424000000ES, , , , , , , , , , , , , , , , , , , , , , 7019, 
10, 19970423220000ES, 19970424000000ES
N, 8234, Rseler, 456123789, ACust, 987654321, N, , CE, MECS, , , 35 
DAILY, FIRM, POINT__TO__POINT, OFF__PEAK, N/A, 19970423000000ES, 
19970423060000ES, 42.00, 24.50, 24.50, 
N,SC:(cust:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123); 
SP:(custR234); SU:(cust:R345), , , , , N, CONFIRMED, , 
19970422121354ES, , Standard daily reservation, System Operator, 
Customer comments, Frank Orth, (999)-123-4567, (999)-123-1231, 
[email protected], Jane Doe, (999)-123-4567, (999)-123-8823, , 7019, 
10, 19970423000000ES, 19970423060000ES 
N, 8235, AEP, 123456789, Cust, 987654321, N, , CE, AMPO, , , 
5, HOURLY, NON-FIRM, POINT__TO__POINT, OFF__PEAK, N/A, 
19970423060000ES, 19970423070000ES, 2.50, 2.50, 6.20, N, 
SC:(cust:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123); 
SP:(custR234); SU:(cust:R345), , , , , N, CONFIRMED, , 
19970422160523ES, , Profile verified, First piece, Customer 
comments, System Operator, (888)-123-4567, (888)-123-1231, 
[email protected], Jane Doe, (999)-123-4567, (999)-123-8823, , 7019, 
10, 19970423000000ES, 19970423060000ES 
Y, , , , , , , , , , , , ,10, , , , , , , 19970423070000ES, 
19970423080000ES, , , , , , , , , , , , , , , , , , , , , , , , 

Y, , , , , , , , , , , , ,15, , , , , , ,19970423080000ES, 
19970423200000ES, , , , , , , , , , , , , , , , , , , , , , , , 

Y, , , , , , , , , , , , ,10, , , , , , , 19970423200000ES, 
19970423210000ES, , , , , , , , , , , , , , , , , , , , , , , , 

Y, , , , , , , , , , , , ,5, , , , , , 19970423210000ES, 
19970423220000ES, , , , , , , , , , , , , , , , , , , , , , , , 

N, 8236, Rseler, 456123789, Cust, 987654321, N, , CE, VP, , , 20, 
HOURLY, FIRM, POINT__TO__POINT, OFF__PEAK, N/A, 19970424040000ES, 
19970424160000ES, 2.00, 2.50, 6.20, N , , ,,, CONFIRMED, , 
19970422160523ES, , Bid price refused, Negotiated

[[Page 54297]]

OFFER__PRICE accepted, Joe Smith, (888)-123-4567, (888)-123-1231, 
[email protected], Jane Doe, (999)-123-4567, (999)-123-8823, , 7019, 
20, 19970423040000ES, 19970423080000ES
Y, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , 
, , , 7880, 10, , , , , , 19970423080000ES, 19970423160000ES
Y, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,, 
, , , 7019, 10, , , , , , 19970423080000ES, 19970423160000ES

4.4.6  Examples 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 the OASIS Node.
    b. The Seller has the option of setting STATUS via the transsell 
Template to one of the following: INVALID, RECEIVED, STUDY, 
COUNTEROFFER, ACCEPTED, DECLINED, or REFUSED.
    c. If the Seller sets STATUS to ACCEPTED (and, as required by 
Section 4.2.10.1i, the OASIS Node forces the Seller to set 
OFFER__PRICE equal to BID__PRICE as a condition to setting STATUS to 
ACCEPTED), the OASIS Node will immediately set STATUS to CONFIRMED.
    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 the OASIS Node.
    b. The Seller has the option of setting the STATUS via the 
transsell Template to one of the following: INVALID, RECEIVED, 
STUDY, ACCEPTED, DECLINED, COUNTEROFFER, or REFUSED. If INVALID (due 
to invalid entries in the request), DECLINED (due to the Seller 
determining that the proposed price is not acceptable and further 
negotiations are not desired), or REFUSED (due to the unavailability 
of the requested service) are set, the transmission reservation 
request is terminated.
    c. If the Seller sets the STATUS to RECEIVED or STUDY, and 
determines that the BID__PRICE is too low, the Seller sets the 
OFFER__PRICE to the price desired, and sets the STATUS to 
COUNTEROFFER 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 the OASIS Node.
    b. The Seller has the option of setting the STATUS via the 
transsell Template to one of the following: INVALID, RECEIVED, 
STUDY, ACCEPTED, DECLINED, COUNTEROFFER, or REFUSED. If INVALID, 
DECLINED, or REFUSED are set, the transmission reservation request 
is terminated.
    c. The Seller determines that the BID__PRICE is too low, sets 
the OFFER__PRICE to the desired value, and sets the STATUS to 
COUNTEROFFER 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 
COUNTEROFFER 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 Declined 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 the OASIS Node.
    b. The Seller has the option of setting the STATUS via the 
transsell Template to one of the following: INVALID, RECEIVED, 
STUDY, ACCEPTED, DECLINED, COUNTEROFFER, or REFUSED. If INVALID, 
DECLINED, or REFUSED are set, the transmission reservation request 
is terminated.
    c. The Seller determines that the BID__PRICE is too low, sets 
OFFER__PRICE to his desired value, and sets STATUS to COUNTEROFFER 
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 DECLINED, indicating that the price is unacceptable and 
that he does not wish to continue negotiations.

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 the OASIS Node.
    b. The Seller has the option of setting the STATUS via the 
transsell Template to one of the following: INVALID, RECEIVED, 
STUDY, ACCEPTED, DECLINED, COUNTEROFFER, or REFUSED. If INVALID, 
DECLINED, or REFUSED are set, the transmission reservation request 
is terminated.
    c. The Seller determines that the BID__PRICE is too low, sets 
the OFFER__PRICE to his desired value, and sets the STATUS to 
COUNTEROFFER 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 
COUNTEROFFER via the transsell Template.
    f. The Customer breaks off all further negotiations by setting 
STATUS to WITHDRAWN (or the Customer/Sellercould go through 
additional iterations of REBID/COUNTEROFFER until negotiations are 
broken off or the reservation is CONFIRMED).

4.4.6.6 Negotiations Superseded by Higher Priority Reservation

    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 the OASIS Node.
    b. The Seller has the option of setting the STATUS via the 
transsell Template to one of the following: INVALID, RECEIVED, 
STUDY, ACCEPTED, DECLINED, COUNTEROFFER, or REFUSED. If INVALID, 
DECLINED, or REFUSED are set, the transmission reservation request 
is terminated.

[[Page 54298]]

    c. If the Seller determines that another reservation has higher 
priority and must displace this request, he sets the STATUS to 
SUPERSEDED and the negotiations are terminated.
    d. However, if desired and permitted by the tariff, the Seller 
may set the STATUS of a request in any of these previous states 
(including COUNTEROFFER and ACCEPTED) to COUNTEROFFER with an 
OFFER__PRICE which could avoid the request being superseded, thus 
allowing the Customer the choice of being SUPERSEDED or accepting 
the proposed OFFER__PRICE.

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

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.
    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 access to TS Information beyond the lowest Access 
Privilege.
    f. Service Request Transactions: Whenever Service Request 
transactions are implemented entirely over OASIS Nodes, 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 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 network:
     The response capabilities of the OASIS Node server to 
process interactions with Users
     The bandwidth of the connection(s) between the OASIS 
Node server and the Internet.
    Therefore, the OASIS response time requirements are as follows:
    a. OASIS Node Server Response Time: The OASIS Node server shall 
be capable of supporting its connection(s) to Users with an average 
aggregate data rate of at least ``A'' bits per second. ``A'' is 
defined as follows:

A = N * R bits/sec

Where:
N = 5% of registered Customers.
and
R = 28,800 bits/sec per Customer.

    b. OASIS Node Network Connection Bandwidth: The bandwidth ``B'' 
of the OASIS Node connection(s) to the Internet shall be at least: B 
= 2 * A bits/sec
    c. Time to Meet Response Requirements: The minimum time 
responses shall be met within 1 month of User registration for any 
single new User. If more than 10 new Users register in one month, 2 
months lead time shall be permitted to expand/upgrade the OASIS 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] TR08OC98.001


[[Page 54299]]


    A Provider account shall be considered to be down, and downtime 
shall be accumulated, upon occurrence of any of the following:
    1. One or more Users cannot link and log on to the Provider 
account. The downtime accumulated shall be calculated as:
     for affected Users of 1/n * (Login Time), which is the 
time used by each affected User to try to link and log on to the 
Provider account, and where ``n'' is the total number of Users 
actively registered for that Provider account.
    2. One or more Users cannot access TS Information once they have 
logged on to a Provider account. The downtime accumulated shall be 
calculated as:
     for affected Users of 1/n * (Access Time), which is 
the time used by each affected User to try to access data, and where 
``n'' is the total number of Users actively registered for that 
Provider.
    3. A five (5) minute penalty shall be added to the cumulative 
downtime for every time a User loses their connection to a 
Provider's account due to an OASIS Node momentary failure or 
problem.

5.5  BACKUP AND RECOVERY

    The following backup and recovery requirements shall be met:
    a. Normal Backup of TS Information: Backup of TS Information and 
equipment shall be provided within the OASIS Nodes so that no data 
or transaction logs are lost or become inaccessible by Users due to 
any single point of failure. Backed up data shall be no older than 
30 seconds. Single points of failure include the loss of one:
     Disk drive or other storage device
     Processor
     Inter-processor communications (e.g. LAN)
     Inter-OASIS communications
     Software application
     Database
     Communication ports for access by Users
     Any other single item which affects the access of TS 
Information by Users
    b. Spurious Failure Recovery Time: After a spurious failure 
situation, all affected Users shall regain access to all TS 
Information within 30 minutes. A spurious failure is a temporary 
loss of services which can be overcome by rebooting a system or 
restarting a program. Permanent loss of any physical component is 
considered a catastrophic failure.
    c. Long-Term Backup: Permanent loss of critical data due to a 
catastrophic failure shall be minimized through off-line storage on 
a daily basis and through off-site data storage on a periodic basis.
    d. Catastrophic Failure Recovery: Recovery from a catastrophic 
failure or loss of an OASIS Node may be provided through the use of 
alternate OASIS Nodes which meet the same availability and response 
time requirements. TSIPs may set up prior agreements with other 
TSIPs as to which Nodes will act as backups to which other Nodes, 
and what procedure will be used to undertake the recovery. Recovery 
from a catastrophic failure shall be designed to be achieved within 
24 hours.

5.6  Time Synchronization

    The following are the time requirements:
    a. Time Synchronization: Time shall be synchronized on OASIS 
Nodes such that all time stamps will be accurate to within ``0.5 
second of official time. This synchronization may be handled over 
the network using NTP, or may be synchronized locally using time 
standard signals (e.g. WWVB, GPS equipment).
    b. Network Time Protocol (NTP): OASIS Nodes shall support the 
Internet tool for time synchronization, Network Time Protocol (NTP), 
which is described in RFC-1305, 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 to 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 download 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.

Appendix A--Data Element Dictionary

[[Page 54300]]



                                                                   September 29, 1998
                                                                       Version 1.3
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                                   Field format:
                                                      minimum
                                                 characters {type
 Data dictionary element name        Alias           of ASCII}           Restricted values                      Definition of data element
                                                      maximum
                                                    characters
--------------------------------------------------------------------------------------------------------------------------------------------------------
AFILIATE__Flag...............  AFFLAG..........  {alphanumeric} 3  Valid Values................  Set to YES if customer is an affiliate of the provider.
                                                                   YES.........................
                                                                   NO..........................
ANC__ SERVICE__ TYPE.........  ANCTYPE.........  1 {ALPHANUMERIC}  Valid types.................  EI__Energy Imbalance.
                                                  20.
                                                                    EI.................  SP__Spinning Reserve.
                                                                    SP.................  SU__Supplemental Reserve.
                                                                    SU.................  RV__Reactive supply and Voltage Control.
                                                                    RV.................  RF__Regulation and Frequency response.
                                                                    RF.................  SC__Scheduling, system Control and Dispatch.
                                                                    SC.................  {Registered} must be registered with www.tsin.com.
                                                                   {Registered}................    and listed in the ANCSERV template.
ANC__SVC__LINK...............  ANCSVCLIN K.....  0 {ALPHANUMERIC}  Formatted string as follows:  The Method for linking ancillary services to a
                                                  300.             SC:(AA); RV: (AA); RF:         transmission service request. The provider and
                                                                   (AA[:xxx[:yyy[:nnn]]]); EI:    capacity of each ancillary service is identified using
                                                                   (AA[:xxx[:yyy[:nnn]]]);        the formatted string:
                                                                   SP: (AA[:xxx[:yyy[:nnn]]]);   SC:(AA); RV: (AA); RF: (AA[:xxx[:yyy[:nnn]]]); EI:
                                                                   SU: (AA[:xxx[:yyy[:nnn]]]);   (AA[:xxx[:yyy[:nnn]]]);
                                                                   {Registered}: (AA[:xxx[:yyy   SP: (AA[:xxx[:yyy[:nnn]]]); SU:
                                                                   [:nnn]]]).                    (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 commpany 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'' groupin 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 Node 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 come from the
                                                                                                  ancillary reservations in the order indicated in the
                                                                                                  codes, on an ``as-needed'' basis.
ANC__SVC REQ.................  ANCSVCREQ.......  0{ALPHANUMERIC}   EI:{M, R, O, }; SP:{ M, R,    Ancillary services required for a transmission services
                                                  100.              O, U}; SU:{, R, O, U}; RV:{   offering The appropriate letter {M, R, O, U} will be
                                                                    M, R, O, U}; RF:{M, R, O,     assigned to each of the six Proforma FERC ancillary
                                                                    U}; SC:{ M, R, O, U};         services (See ANC__SERVICE__TYPE), where the letters
                                                                    {registered]:{ M, R, O, U}.   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
ASSIGNMENT__REF..............  AREF............  1{ALPHANUMERIC}1  Unique value................  A unique reference number assigned by a Transmission
                                                  2.                                              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 a STOP TIME.
BID__PRICE...................  BIDPR...........  1{NUMERIC}5 +     Positive number with 2        The current bid price of a Service in dollars and
                                                  ``.''             decimals.                     cents. Used by Customers to designate a price being
                                                  +2{NUMERIC}2.                                   bid.

[[Page 54301]]

CAPACITY.....................  CAP.............  1{NUMERIC}12....  Non-negative number in units  Transfer capability is the measure of the ability of
                                                                    of MW.                        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 units  The amount of transfer capability curtailed by the
                                                                    of MW.                        Primary provider for emergency reasons.
CAPACITY__ SCHEDULED.........  CAPSCH..........  0{NUMERIC}12....  Non-negative number in units  Transfer capability scheduled on each path.
                                                                    of MW.
CATEGORY.....................  CAT.............  0{ALPHANUMERIC}2  Valid name from CATEGORY in   A name to be used to categorize messages. Valid names
                                                  5.                LIST Template.                would include:, Want-Ad, Curtailment, Outage, Oasis
                                                                                                  Maint Notice.
CEILING__ PRICE..............  CEILPR..........  1{NUMERIC}5 +     Positive number with 2        Ceiling price of the Service as entered by the
                                                  ``.''+2{NUMERIC   decimals.                     Transmission Provider.
                                                  }2.
COLUMN__ HEADERS.............  HEADERS.........  1{ALPHANUMERIC}   Headers surrounded with A     Example: COLUMN__ HEADER=APATH__ NAME'', ``POINT__ OF__
                                                  Limited to all    and separated by commas.      RECEIPT'', ``POINT__OF__ DELIVERY'',
                                                  the elements      Limited to valid Template     ``SOURCE'',``SINK''.
                                                  names in one      element names. Must use
                                                  Template.         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}2  Valid name of a control area  A part of the power system with metered tie lines and
                                                  0.                                              capable of matching generation and load while meeting
                                                                                                  scheduled interchange. Location of Ancillary Services
                                                                                                  is my CONTROL AREA.
CURAILMENT OPTIONS...........  CUROPT..........  0{ ALPHANUMERIC}  Free form text..............  Customer options, if any, to avoid curtailment.
                                                  80.
CURTAILMENT__ PROCEDURES.....  CURPROC.........  0{                Free form text..............  Curtailment procedures to be followed in the event of a
                                                  ALPHANUMERIC}80.                                curtailment.
CURTAILMENT__ REASON.........  CURREAS.........  0{ALPHANUMERIC}8  Free-form text..............  Reason for curtailment of service.
                                                  0.
CUSTOMER__CODE...............  CUST............  1{ALPHANUMERIC}6  Unique value, registered on   Any entity (or its designated agent) that is eligible
                                                                    TSIN.COM.                     to view OASIS information, to execute a service
                                                                                                  agreement, and/or to receive transmission service.
CUSTOMER COMMENTS............  CUSTCOM.........  0{ALPHANUMERIC}8  Free-form text..............  Informative text.
                                                  0.
CUSTOMER__DUNS...............  CUSTDUNS........  9{NUMERIC}9.....  Unique DUNS number..........  Unique DUNS number for a Customer.
CUSTOMER__EMAIL..............  CUSTEMAIL.......  1{ALPHANUMERIC}2  Valid Internet E-Mail         Internet E-Mail address of Customer contact person.
                                                  5.                address.
CUSTOMER__FAX................  CUSTFAX.........  14{ALPHANUMERIC}  Area code and telephone       FAX phone number of Customer contact person.
                                                  20.               number, plus any extensions
                                                                    (aaa)-nnn-nnnn xnnnn.
CUSTOMER__NAME...............  CUSTNAME........  1{ALPHANUMERIC}2  Free form text..............  Name of Customer contact person.
                                                  5.
CUSTOMER__PHONE..............  CUSTPHON........  14{ALPHANUMERIC}  Area code and telephone       Telephone of Customer contact person.
                                                  20.               number, plus any extensions
                                                                    (aaa)-nnn-nnnn-xnnnn.
DATA__ROWS...................  ROWS............  1{NUMERIC}unlimi  Positive Number.............  Number of records (rows) of data exclusive of header
                                                  ted.                                            information that are to be uploaded or downloaded in a
                                                                                                  file.
DATE__TIME__ EFFECTIVE.......  TIMEEFCT........  16{ALPHANUMERIC}  Valid date and time in        Date and time a message or service offer is in effect.
                                                  16.               seconds.
                                                                   yyyy+mo+dd+hh...............
                                                                   +mm+ss+tz...................
DEAL__REF....................  DREF............  0{ALPHANUMERIC}1  Unique value, Assigned by     The unique reference assigned by a Customer to two or
                                                  2.                Customer.                     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}1  Free form text..............  A detailed description of the discretion being
                                                  000.                                            reported.
ELEMENT__NAME................  ELEMENT.........  1{ALPHANUMERIC}4  Valid Template element name.  Template element name as indicated in data dictionary.
                                                  0.
EMPLOYEE__NAME...............  EMPNAME.........  1{ALPHANUMERIC}2  Free form text..............  Name of person who is transferring from one position to
                                                  5.                                              another.
ERROR__MESSAGE...............  ERROR...........  1{ALPHANUMERIC}2  Free form text..............  Error message related to a RECORD__STATUS or REQUEST
                                                  50.                                             STATUS.
FORMER__COMPANY..............  FORMCO..........  1{ALPHANUMERIC}2  Free form text..............  Former company of the person who is transferring.
                                                  5.
FORMER__ DEPARTMENT..........  FORMDEPT........  1{ALPHANUMERIC}2  Free form text..............  Former position held by the person who is transferring.
                                                  5.
FORMER__POSITION.............  FORMPOS.........  1{ALPHANUMERIC}2  Free form text..............  Former position held by the person who is transferring.
                                                  5.
INTERFACE__TYPE..............  INTERFACE.......  0{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}5  Free form text..............  Item from LIST, such as list of SELLER, list of
                                                  0.                                              PATH__NAME, list of POINT__OF__RECEIPT, list of
                                                                                                  POINT__ OF__ DELIVERY, list of SERVICE__ INCREMENT,
                                                                                                  list of TS__ CLASS, list of TS__ TYPE, list of TS__
                                                                                                  PERIOD, list of TS__WINDOW, list of TS__ SUBCLASS,
                                                                                                  list of ANC__ SERVICE__ TYPE, list of NERC __
                                                                                                  CURTAILMENT __ PRIORITY, list of OTHER__ CURTAILMENT__
                                                                                                  PRIORITY, list of CATEGORY, list of TEMPLATE, list of
                                                                                                  LIST.
LIST__ ITEM__ DESCRIPTION....  ITEMDESC........  0{ALPHANUMERIC}1  Free form text..............  A detailed description of the LIST__ITEM.
                                                  00.

[[Page 54302]]

LIST__NAME...................  LIST............  1{ALPHANUMERIC}5  LIST, SELLER, PATH, POR,      List of valid names for each of the types of lists. The
                                                  0.                POD, SERVICE__ INCREMENT,     minimum set of lists defined must be implemented.
                                                                    TS__ CLASS, TS__ TYPE, TS__
                                                                    PERIOD, TS__ SUBCLASS,
                                                                    ANC__ SERVICE__ TYPE,
                                                                    NERC__ CURTAILMENT__
                                                                    PRIORITY, OTHER__
                                                                    CURTAILMENT__ PRIORITY,
                                                                    CATEGORY, TEMPLATE.
MESSAGE......................  MSG.............  1{ALPHANUMERIC}2  Free form text..............  An informative text message.
                                                  00.
NEGOTIATED__PRICE__FLAG......  NGPRIFLG........  0{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{ALPHANUMERIC}1  Integer 1-7.................  One of the NERC seven curtailment priorities,
                                                                                                  documented in LIST template.
NEW__ COMPANY................  NEWCO...........  1{ALPHANUMERIC}2  Free form text..............  New company of the person who is transferring.
                                                  5.
NEW__DATA....................  NEWDATA.........  0{ALPHANUMERIC}2  Any valid date element value  For audit log, the new updated value of a Template data
                                                  00.                                             element after update.
NEW__DEPARTMENT..............  NEWDEPT.........  1{ALPHANUMERIC}2  Free form text..............  New department of the person who is transferring.
                                                  5.
NEW__POSITION................  NEWPOS..........  1{ALPHANUMERIC}2  Free form text..............  New position held by the person who is transferring.
                                                  5.
OFFER__PRICE.................  OFFPR...........  1{NUMERIC}5       Positive number with 2        The current offered price of a Service in dollars and
                                                  +''.'' +          decimals.                     cents. Used by the Seller to indicate the offering
                                                  2{NUMERIC}2.                                    price.
OFFER__ START__TIME..........  OFFSTIME........  0,16{             Valid Date and Time to        Start time of the window during which a Customer may
                                                  ALPHANUMERIC}     seconds:.                     request a discounted offer. If null, no restrictions
                                                  16.              yyy + mo + dd + hh + mm + ss   on the start of the offering time is implied (other
                                                                    + tz.                         than tariff requirements).
OFFER__ STOP__TIME...........  OFFSPTIME.......  0,16{             Valid Date and Time to        Stop time of the window during which a Customer may
                                                  ALPHANUMERIC}     seconds:.                     request a discounted offer. (Expiration time of an
                                                  16.              yyy + mo + dd + hh + mm + ss   offer). If null, no restrictions on the end of the
                                                                    + tz.                         offering time is implied (other than tariff
                                                                                                  requirements).
OLD__DATA....................  OLDDATA.........  0{ ALPHANUMERIC}  Any valid data element value  For audit log, the old value of a Template data element
                                                  200.                                            prior to being updated. This element is not applicable
                                                                                                  in the audit log for transaction events.
OPTIONAL__CODE...............  N/A.............  0{ ALPHANUMERIC}  Unique path name within       OPTIONAL__CODE--25 chars, unique for Path. If used for
                                                  25.               region.                       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__          OTHCUR..........  O{ALPHANUMERIC}8  Free form text..............  Other than NERC curtailment priorities, such as
 PRIORITY.                                                                                        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.
PATH__ CODE..................  N/A.............  0{ALPHANUMERIC}1  Unique code for each path as  Unique code within a Region for each path. Used by PATH
                                                  2.                defined by primary provider.  NAME.
PATH__NAME...................  PATH............  5{ALPHANUMERIC}5  Unique value................  The unique name assigned to a single transmission line
                                                  0.                                              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 ``/''. 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 all represent POD.
                                                                                                 SPARE__CODE--3 chars.
POINT__ OF__ DELIVERY........  POD.............  1{ALPHANUMERIC}1  Unique value within Primary   Point of Delivery is one or more point(s) of
                                                  2.                Provider.                     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}  Unique value within Primary   Point of Receipt is one or more point(s) of
                                                  12.               Provider.                     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}  Free form text..............  Name of person who is posting the information on the
                                                  25.                                             OASISNode
POSTING__REF.................  POSTREF.........  1{ALPHANUMERIC}1  Unique Value................  Assigned by TSIP when Service or Message is received by
                                                  2.                                              TSIP. Unique number can be used by the user to modify
                                                                                                  or delete the posting.

[[Page 54303]]

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...........  0(ALPHA)20......  Free form text..............  The units used for CEILING__ PRICE, OFFER__ PRICE, AND
                                                                                                  BID__ PRICE.
                                                                                                 Examples: $/MWhr, $/MWmonth
PRIMARY__ PROVIDER__ COMMENTS  PPROVCOM........  0{ ALPHANUMERIC}  Free-form text..............  Informative text. Usually entered by the Primary
                                                  80.                                             Provider through a back end system.
PRIMARY__ PROVIDER__ COD E...  PROVIDER........  1{ ALPHANUMERIC}  Unique Code.................  Unique code for each Primary Provider. Used by
                                                  4.                                              PATH__NAME and in URL. Registered as part of URL at
                                                                                                  www.tsin.com.
PRIMARY__ PROVIDER__ DUN S...  PPROVDUNS.......  9{ NUMERIC} 9...  Valid DUNS number...........  Unique code for each Primary. Provided by Dun and
                                                                                                  Bradstreet.
REASSIGNED__ CAPACITY........  RASCAP..........  1{ NUMERIC} 12..  Postive number, cannot        The amount of transfer capability that was reassigned
                                                                    exceed previous assigned      from one entity to another.
                                                                    capacity.
REASSIGNED__ REF.............  REREF...........  1{ ALPHANUMERIC}  Unique value................  When customer makes a purchase of a transmission
                                                  12.                                             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 SECONDARY over alternative points of delivery.
REASSIGNED__ START__ TIME....  RESSTIME........  16{               Valid date and time to        Beginning date and time of the reassigned transmission
                                                  ALPHANUMERIC}     seconds:.                     service
                                                  16.              yyyy + mo + dd + hh + tz....
REASSIGNED__ STOP__ TIME.....  RESSPTIME.......  16{               Valid date and time to hour:  Date and time of the end of the transmission service
                                                  ALPHANUMERIC}    yyyy + mo + dd + hh + tz....   that is reassigned to another user.
                                                  16.
RECORD__ STATUS..............  RECSTATUS.......  1{ NUMERIC} 3...  Error number................  Record status indicating record was successful or error
                                                                                                  code if unsuccessful.
                                                                                                 200=Successful
REGION__ CODE................  N/A.............  1{ ALPHANUMERIC}  Unique within OASIS System..  Defined for NERC regions, with the following defined:
                                                  2.                                             E__ ECAR.
                                                                                                 I__ MAIN.
                                                                                                 S__ SERC.
                                                                                                 T__ ERCOT.
                                                                                                 A__ MAPP.
                                                                                                 P__ SPP.
                                                                                                 M__ MAAC.
                                                                                                 N__ NPCC.
                               ................  ................  ............................  W__WSCC.
                                                                                                 F__FRCC.
                                                                                                 Second character or digit reserved for subregion id as
                                                                                                  defined by each region.
REQUEST__ REF................  RREF............  0{ ALPHANUMERIC}  Unique value................  A reference uniquely assigned by a Customer to a
                                                  12.                                             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{               Valid date and time to        Date and time to seconds by when a response must be
                                                  ALPHANUMERIC}     seconds: yyyy + mo + dd +     received from a Customer.
                                                  16.               hh +mm + ss + tz.
RESPONSIBLE__ PARTY__ NAME...  PARTNAME........  1{ ALPHANUMERIC}  Free form text..............  The name of the person responsible for granting the
                                                  25.                                             discretion.
RETURN__ TZ..................  TZ..............  2{ ALPHANUMERIC}  AD, AS, PD, PS, ED, ES, MD,   A time zone code, indicating the base time zone, and
                                                  2.                MS, CD, CS, 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............  0{ ALPHANUMERIC}  Unique value................  Identifier which is set by seller (including Primary
                                                  12.                                             Provider) when posting a service for sale.
SELLER__ CODE................  SELLER..........  1{ ALPHANUMERIC}  Unique value................  Organization name of Primary Provider or Reseller.
                                                  6.
SELLER__ COMMENTS............  SELCOM..........  0{ ALPHANUMERIC}  Free-form text..............  Informative text provided by the Seller.
                                                  80.
SELLER__ DUNS................  SELDUNS.........  9{ Numeric} 9...  Valid DUNS number...........  Unique Date Universal Numbering System provided by Dun
                                                                                                  and Bradstreet. Code for a Primary Provider or Seller.
SELLER__ EMAIL...............  SELEMAIL........  5{ ALPHANUMERIC}  Valid network reference.....  E-mail address of Seller contact person.
                                                  60.
SELLER__ FAX.................  SELFAX..........  14{               Area code and telephone       The fax telephone number for contact person at Seller.
                                                  ALPHANUMERIC}     number, plus any extensions
                                                  20.               Example: (aaa)-nnn-nnnn
                                                                    xnnnn.
SELLER__ NAME................  SELNAME.........  1{ ALPHANUMERIC}  Free form text..............  The name of an individual contact person at the Seller.
                                                  25.
SELLER__ PHONE...............  SELPHONE........  14{               Area code and telephone       The telephone number of a contact person as a Seller.
                                                  ALPHANUMERIC}     number, plus any extensions
                                                  20.               (aaa)-nnn-nnnn xnnnn.
SERVICE__ DESCRIPTION........  SVCDESC.........  0{ ALPHANUMERIC}  Free-form text..............  Information regarding a service.
                                                  200.
SERVICE__ INCREMENT..........  SRVINCR.........  1{ ALPHANUMERIC}  Valid increments............  The transmission service increments provided. Five are
                                                  8.                HOURLY                pre-defined, while additional increments can be used
                                                                    Daily                 if they are registered on TSIN.COM and shown in the
                                                                    Weekly                Provider's LIST template.
                                                                    Monthly
                                                                    Yearly
                                                                    { Registered}
SERVICE__ NAME...............  SVCNAME.........  1{ ALPHANUMERIC}  Free-form text..............  Name of service affected by the discretionary action.
                                                  25.
SERVICE__ TYPE...............  SVCTYPE.........  1{ ALPHANUMERIC}  Free-form text..............  Type of service affected by the discretionary action.
                                                  25.
SINK.........................  SINK............  0{ ALPHANUMERIC}  Valid area name.............  The area in which the SINK is located.
                                                  14.
SOURCE.......................  SOURCE..........  0{ ALPHANUMERIC}  Valid area name.............  The area in which the SOURCE is located.
                                                  14.

[[Page 54304]]

SPARE__ CODE.................  N/A.............  0{ ALPHANUMERIC}  Defined by region...........  Spare code to be used at a later time. Used by
                                                  3.                                              PATH__NAME.
STANDARDS__ OF__ CONDUCT__     STDISSUE........  0{ ALPHANUMERIC}  Free-form text..............  Issues that were in violation of the FERC Standards of
 ISSUES.                                          800.                                            Conduct. This text may include a reference pointer to
                                                                                                  a more detailed description.
START__ TIME.................  STIME...........  16{               Valid Date and Time to        Start date and clock time of a service. When used as a
                                                  ALPHANUMERIC}     seconds:.                     query variable, it requires the return of all items
                                                  16.                                             whose
                                                                   yyyy + mo + dd + hh + mm +    Stop time is after the Start time. Note that for some
                                                                    ss + tz.                      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{               Valid Date and Time to        Query parameter to indicate all the records are to be
                                                  ALPHANUMERIC}     seconds:.                     retrieved that were posted on or after this time.
                                                  16.              yyyy + mo + dd + hh + mm +
                                                                    ss + tz.
START__ TIME__ QUEUED........  STIMEQ..........  16{               Valid Date and Time to        Start date and clock time of a service, used for
                                                  ALPHANUMERIC}     seconds:                      requesting transactions queued after this time.
                                                  16.              yyyy + mo + dd + hh + mm +
                                                                    ss + tz.
STATUS.......................  STATUS..........  5{ ALPHANUMERIC}  Valid field (QUEUED,          QUEUED=initial status assigned by TSIP on receipt of
                                                  25.               INVALID, RECEIVED, STUDY,     ``customer services purchase request''.
                                                                    REBID, COUNTEROFFER,         INVALID=assigned by TSIP or Provider indicating an
                                                                    DECLINED, SUPERSEDED,         invalid field in the request, such as improper POR,
                                                                    ACCEPTED, REFUSED,            POD, source, sink, etc. (Final state).
                                                                    CONFIRMED, WITHDRAWN,        RECEIVED=assigned by Provider or Seller to acknowledge
                                                                    DISPLACED, ANNULLED,          QUEUED requests and indicate the service request is
                                                                    RETRACTED).                   being evaluated, including for completing the required
                                                                                                  ancillary services.
                                                                                                 STUDY=assigned by Provider or Seller to indicate some
                                                                                                  level of study is required or being performed to
                                                                                                  evaluate service request.
                                                                                                 REFUSED=assigned by Provider or Seller to indicate
                                                                                                  service request has been denied due to availability of
                                                                                                  transmission capability. SELLER__COMMENTS should be
                                                                                                  used to communicate details for denial of service.
                                                                                                  (Final state).
                                                                                                 COUNTEROFFER=assigned by Provider or Seller to indicate
                                                                                                  that a new OFFER__ PRICE is being proposed.
                                                                                                 REBID=assigned by Customer to indicate that a new
                                                                                                  BID__PRICE is being proposed.
                                                                                                 SUPERSEDED=assigned by Provider or Seller when a
                                                                                                  request which has not yet been confirmed is displaced
                                                                                                  by another reservation request. (Final state).
                                                                                                 ACCEPTED=assigned by Provider or Seller to indicate the
                                                                                                  service request at the designated OFFER__PRICE has
                                                                                                  been approved/accepted. If the reservation request was
                                                                                                  submitted PRECONFIRMED, the TSIP 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.
                                                                                                 DECLINED=assigned by the Provider or Seller to indicate
                                                                                                  that the BID__PRICE is unacceptable and that
                                                                                                  negotiations
                                                                                                 RETRACTED = assigned by Provider or Seller when the
                                                                                                  Customer fails to confirm or withdraw an accepted
                                                                                                  updated offer within the required time period. (Final
                                                                                                  state).
                                                                                                 WITHDRAWN = assigned by the Customer at any point in
                                                                                                  request evaluation to withdraw the request from any
                                                                                                  further action. (Final state).
                                                                                                 CONFIRMED = assigned by the Customer in response to the
                                                                                                  Provider or Seller posting ``ACCEPTED'' status, to
                                                                                                  confirm service. Once a request has been
                                                                                                  ``CONFIRMED'', a transmission service reservation
                                                                                                  exists. (Final state, unless overridden by DISPLACED
                                                                                                  or ANNULLED state).
                                                                                                 DISPLACED = assigned by Provider or Seller when a
                                                                                                  ``CONFIRMED'' reservation from a Customer is displaced
                                                                                                  by a longer term request, and the Customer has
                                                                                                  exercised right of first refusal (i.e. refused to
                                                                                                  match terms of new request). (Final state).
                                                                                                 ANNULLED = assigned by Provider or Seller when, by
                                                                                                  mutual agreement with the Customer, a confirmed
                                                                                                  reservation is to be voided. (Final state).
STATUS__ COMMENTS............  STACOM..........  0{ ALPHANUMERIC}  Free form text..............  Informative text.
                                                  80.
STATUS__ NOTIFICATION........  STATNOT.........  0{ ALPHANUMERIC}  http://URL: portnumber/       The STATUS__NOTIFICATION data element shall contain the
                                                  200.              directory/cgi script/query    protocol field ``http:'', which designates the
                                                                    parameters or.                notification method/protocol to be used, followed by
                                                                   Mailto: ....   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

[[Page 54305]]

STOP__ TIME..................  SPTIME..........  16{               Valid date and time.........  Stop date and clock time. When used as a query
                                                  ALPHANUMERIC}    yyyy + mo + dd + hh +mm +ss    variable, it requires the return of all items which
                                                  16.               +tz.                          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{} 16.
STOP__ TIME__ QUEUED.........  SPTIMEQ.........  16{               Valid Date and Time to        Stop date and clock time, used for requesting
                                                  ALPHANUMERIC}     seconds:.                     transactions queued before this time.
                                                  16.              yyyy + mo + dd + hh + mm +
                                                                    ss + tz.
SUBJECT......................  SUBJ............  0{ALPHANUMERIC}   Free form text..............  Informative text used to summarize a topic in a
                                                  80.                                             message.
TARIFF__ REFERENCE...........  TARIFF..........  0{ ALPHANUMERIC}  Free form text. Name and      Tariffs approved by FERC.
                                                  150.              description of Tariff.
TEMPLATE.....................  TEMPL...........  1{APHANUMERIC}20  Valid name of Template from   The name of a logical collection DATE__ELEMENTS in a
                                                                    Section 4.3 or from LIST      User's interaction with an OASIS Node.
                                                                    Template.
TIME__ OF __LAST__UPDATE.....  TLUDATE.........  16{APHANUMERIC}   Valid date and time to        Date and time to seconds that data was last updated.
                                                  16.               seconds:                      May be used to search data updated since a specific
                                                                   yyy + mo + dd + hh = + mm +    point in time.
                                                                    ss + tz.
TIME__POSTED.................  TIMEPST.........  16{APHANUMERIC}   Valid Date and Time to        Date and time a message is posted.
                                                  16.               seconds:.
                                                                   yyy + mo + dd + hh + mm + ss
                                                                    + tz
TIME__QUEUED.................  TIMEQ...........  16{APHANUMERIC}   Valid Date and Time to        Date and time that the request was queued.
                                                  16.               seconds:3.
                                                                   yyy + mo + dd + hh + mm + ss
                                                                    + tz
TIME__STAMP..................  TSTAMP..........  16{APHANUMERIC}   Valid date and Time to        Time data is created.
                                                  16.               seconds.
                                                                   yyy + mo + dd + hh + mm + ss
                                                                    + tz.
TS__CLASS....................  TSCLASS.........  1{APHANUMERIC}    Valid classes:                The transmission service classes provided. Four are pre-
                                                  20.               FIRM                  defined, while additional classes can be used if they
                                                                    NON-FIRM              are registered on TSIN.COM and shown in the Provider's
                                                                    TTC                   LIST template page. SECONDARY is defined as alternate
                                                                    SECONDARY             points of receipt or delivery for POINT__TO__POINT, or
                                                                    Registered}           as nondesignated resources for NETWORK service.
TS__PERIOD...................  TSPER...........  1{APHANUMERIC}    Valid periods                 The transmission service periods provided. Three are
                                                  20.              ON__PEAK                       pre-defined, while additional periods can be used if
                                                                   OFF__PEAK                      they are registered on TSIN.COM and shown in the
                                                                   FULL__PERIOD                   Provider's LIST template.
                                                                   {Registered}
TS__SUBCLASS.................  TSSUBC..........  0{ALPHANUMERIC}.  Free Form...................  The transmission service subclasses provided. These are
                                                                                                  freefrom.
TS__TYPE.....................  TSTYPE..........  1{APHANUMERIC}    Valid types.................  The transmission service types provided. Three are pre-
                                                  20.               POINT__ TO__ POINT.   defined, while additional types can be used if they
                                                                    NETWORK............   are registered on TSIN.COM and shown in the Provider's
                                                                    ACT................   LIST template.
                                                                    {Registered}.......
TS__WINDOW...................  TSWIND..........  1{APHANUMERIC}    Valid windows...............  The transmission service windows provided. Three are
                                                  20.               FIXED..............   pre-defined, while additional windows can be used if
                                                                    SLIDING............   they are registered on TSIN.COM and shown in the
                                                                    EXTENDED...........   Provider's LIST template.
                                                                    {Registered}.......
TZ...........................  TZ..............  2{APHANUMERIC} 2  Valid time zone and           Time zones:
                                                                    indication whether daylight  Atlantic time=AD, AS.
                                                                    savings time is to be used.  Eastern time=ED, ES
                                                                                                 Central time=CD, CS
                                                                                                 Mountain time=MD, MS.
                                                                                                 Pacific time=PD, PS.
                                                                                                 Universal time=UT.
VALID__FROM__TIME............  VALFTIME........  16{PHANUMERIC} 6  Valid date and time.........  Date and time after which the message is valid.
                                                                   yyy + mo + dd + hh + mm + ss
                                                                    + tz
VALID__TO__TIME..............  VALTTIME........  16{PHANUMERIC}    ............................  Date and time before which the message is valid.
                                                  16.              yyy + mo + dd + hh..........
                                                                    + mm + ss + tz.............
VERSION......................  VER.............  1{APHANUMERIC} 6  Range of 1.0 to 9999.9......  Specifies which version of the OASIS Standards and
                                                                                                  Communication Protocol to use when interpreting the
                                                                                                  request.
--------------------------------------------------------------------------------------------------------------------------------------------------------


[[Page 54306]]

    Open Access Same-Time Information System and Standards of 
Conduct
    Docket No. RM95-9-003
    (Issued September 29, 1998)
    BAILEY, Commissioner, concurring
    Several months ago, I dissented from the decision to require the 
unmasking and public posting of source and sink information on the 
OASIS. See Open Access Same-Time Information System and Standards of 
Conduct, 83 FERC para. 61,360 (1998), reh'g pending. Because today's 
decision to delay for two months the obligation to post source and 
sink information on the OASIS is better than no delay at all (though 
not good as a decision to delay indefinitely the posting 
obligation), I respectfully concur with today's order.
Vicky A. Bailey,
Commissioner.
[FR Doc. 98-26678 Filed 10-7-98; 8:45 am]
BILLING CODE 6717-01-P