Open Access Same-Time Information System and Standards of Conduct
Federal RegisterJul 20, 1998
Ask Donna
What actually matters in this document.
Text
SUMMARY: In this order, the Federal Energy Regulatory Commission (the
Commission): finds that ``source and sink'' information must be
unmasked at the time when a transmission provider updates the
transmission reservation posting to show the customer's confirmation
that it wishes to finalize a transaction; implements interim procedures
for the on-line negotiation of transmission service price discounts;
and adopts a comprehensive update of the OASIS Standards and
Communications Protocols Document that implements a number of findings
made by the Commission in Order No. 889-A and in response to industry
suggestions.
DATES: The current S&CP Document (Version 1.1), as modified to
incorporate the interim procedures on price negotiation, is to become
effective on September 18, 1998. The revised S&CP Document (Version
1.2) is to become effective on December 1, 1998. The revisions to the
S&CP Document in Sec. 4.3.7.b, pertaining to the masking of source and
sink information, are to become effective on January 1, 1999.
FOR FURTHER INFORMATION CONTACT:
Marvin Rosenberg (Technical Information), Office of Economic Policy,
Federal Energy Regulatory Commission, 888 First Street, N.E.,
Washington, D.C. 20426, (202) 208-1283
William C. Booth (Technical Information), Office of Electric Power
Regulation, Federal Energy Regulatory Commission, 888 First Street,
N.E., Washington, D.C. 20426, (202) 208-0849
Gary D. Cohen (Legal Information), Office of the General Counsel,
Federal Energy Regulatory Commission, 888 First Street, N.E.,
Washington, D.C. 20426, (202) 208-0321
SUPPLEMENTARY INFORMATION: In addition to publishing the full text of
this document in the Federal Register, the Commission also provides all
interested persons an opportunity to inspect or copy the contents of
this document during normal business hours in the Public Reference Room
at 888 First Street, N.E., Room 2A, Washington, D.C. 20426.
The Commission Issuance Posting System (CIPS) provides access to
the texts of formal documents issued by the Commission. CIPS can be
accessed via Internet through FERC's Homepage (http://www.ferc.fed.us)
using the CIPS Link or the Energy Information Online icon. The full
text of this document will be available on CIPS in ASCII and
WordPerfect 6.1 format. CIPS is also available through the Commission's
electronic bulletin board service at no charge to the user and may be
accessed using a personal computer with a modem by dialing 202-208-
1397, if dialing locally, or 1-800-856-3920, if dialing long distance.
To access CIPS, set your communications software to 19200, 14400,
12000, 9600, 7200, 4800, 2400, or 1200 bps, full duplex, no parity, 8
data bits and 1 stop bit. User assistance is available at 202-208-2474
or by E-mail to [email protected]
This document is also available through the Commission's Records
and Information Management System (RIMS), an electronic storage and
retrieval system of documents submitted to and issued by the Commission
after November 16, 1981. Documents from November 1995 to the present
can be viewed and printed. RIMS is available in the Public Reference
Room or remotely via Internet through FERC's Homepage using the RIMS
link or the Energy Information Online icon. User assistance is
available at 202-208-2222, or by E-mail to [email protected]
Finally, the complete text on diskette in WordPerfect format may be
purchased from the Commission's copy contractor, La Dorn System
Corporation. La Dorn Systems Corporation is located in the Public
Reference Room at 888 First Street, N.E., Washington, D.C. 20426.
Table of Contents
I. Background
II. Discussion
A. Overview
B. Masking of Source and Sink Related Information
1. Business Sensitivity and Competitive Effect
2. Other Information Sources and the Need for Source and Sink
Information
3. Differing Impacts on Contract Path and Flow-Based
Transmission Pricing Regimes
C. Proposed Interim Procedures to Achieve On-Line Price
Negotiation and Disclosure of Discounts in Phase I OASIS until Phase
IA Changes Are Implemented
D. How Group Proposals to Revise the S&CP Document
1. Comments on Preconfirmed Reservations
2. Comments on Linking Ancillary and Transmission Services
3. Comments on Capacity Profiles
4. Comments on Posting of Losses
5. Revisions to Phase IA S&CP Document Recommended by the How
Group and the Commercial Practices Group
E. Other Proposed Revisions to the S&CP Document
1. Comments on Standardized Naming of Transmission Paths
2. Comments on Reservation Templates
3. Comments on Dynamic Notification of Secondary Providers
4. Comments on Reservation Time Limits
F. Data Elements in the Templates Are to be Fixed in Sequence
and Number, and Are Not to Differ Among OASIS Nodes
G. The Meaning of Disclosure of a ``Discount Given to Particular
Customer''
H. Date of Implementation for Phase IA Changes
I. Impact of Phase IA Implementation
J. Uniform Formats for Organizational Charts and Job
Descriptions
III. Effective Date and Congressional Notification
Attachment 1--ABBREVIATIONS OF NAMES USED IN ORDER
Attachment 2--Revised ``STANDARDS AND COMMUNICATION PROTOCOLS FOR
OPEN ACCESS SAME-TIME INFORMATION SYSTEM (OASIS) Phase IA'' (clean
version)
Attachment 3--Revised ``STANDARDS AND COMMUNICATION PROTOCOLS FOR
OPEN ACCESS SAME-TIME INFORMATION SYSTEM (OASIS) Phase IA'' (with
revisions to OASIS How Group's most recent submittal highlighted)
Before Commissioners: James J. Hoecker, Chairman; Vicky A. Bailey,
William L. Massey, Linda Breathitt, and Curt Hebert, Jr.
Order on OASIS-Related Issues
I. Background
The Commission has determined that open access non-discriminatory
transmission service requires that information about the transmission
system must be made available to all transmission users at the same
time by way of the Open Access Same-Time Information System
(OASIS).1 The
[[Page 38885]]
current Phase I OASIS is an Internet-based electronic communication and
reservation system through which transmission providers 2
furnish potential transmission customers with information pertaining to
the availability and price of transmission and ancillary services and
potential customers may select and procure those services in the form
of service reservations.3 To ensure that individual OASIS
nodes present information in a consistent and uniform manner, the
Commission has relied upon the industry to develop standards and
protocols for the Commission's review and approval that specify, among
other things, OASIS templates defining the information that must be
presented to customers interested in procuring transmission-related
services, both in the interactive form of graphical displays or
screens, and in the form of downloadable files. To this end, EPRI and
NERC have jointly facilitated the ongoing activities of the OASIS
``How'' Working Group (How Group) 4 to develop suitable
OASIS standards and communications protocols.5 In this
order, we address several OASIS matters raised in connection with our
directives in Order No. 889-A, various submittals from the How Group,
and comments from interested persons.6
---------------------------------------------------------------------------
\1\ Open Access Same-Time Information System and Standards of
Conduct, Order No. 889, FERC Stats. & Regs. para. 31,035, 61 FR
21,737 (1996); order granting request for clarification, 77 FERC
para. 61,335 (1996); order on reh'g, Order No. 889-A, FERC Stats. &
Regs. para. 31,049, 62 FR 12484 (1997); and order denying reh'g,
Order No. 889-B, 81 FERC para. 61,253, 62 FR 64715 (1997).
See also Promoting Wholesale Competition Through Open Access
Non-Discriminatory Transmission Services by Public Utilities;
Recovery of Stranded Costs by Public Utilities and Transmitting
Utilities, Order No. 888, FERC Stats. & Regs. para. 31,036, 61 FR
21540 (1996); order on reh'g, Order No. 888-A, FERC Stats. & Regs.
para. 31,048, 62 FR 12274, 62 FR 64688 (1997); order on reh'g, Order
No. 888-B, 81 FERC para. 61,248 (1997); and order on reh'g, Order
No. 888-C, 82 FERC para. 61,046 (1998).
\2\ The term ``Transmission Provider'' is defined at
Sec. 37.3(a) of the Commission's OASIS regulations, 18 CFR Part 37
(1997), as:
``any public utility that owns, operates, or controls facilities
used for the transmission of electric energy in interstate
commerce.''
\3\ Early work on OASIS development has focused on facilitating
the more frequently sought short term point-to-point transmission
related services. Phase I of OASIS development has involved the
establishment of basic OASIS sites (nodes) by each transmission
provider, by January 3, 1997, with ongoing refinements that permit
potential transmission customers to reserve transmission capacity
and related services. OASIS Phase II contemplates fully functional
OASIS nodes that additionally will allow on-line scheduling of
transmission service and of the energy associated with transmission
service that now must be accomplished off-OASIS by facsimile or
telephone.
\4\ A list of the abbreviations of names used in this order is
provided in Attachment 1.
\5\ Section 37.5(b)(2) of the OASIS regulations, 18 CFR
37.5(b)(2) (1997), requires that each transmission provider operate
its OASIS node in compliance with the standardized procedures
specified in the OASIS Standards and Communications Protocols
document (referred to herein as the S&CP Document).
\6\ In Order No. 889-A, we directed a number of changes to OASIS
that are listed at note 64, infra. The submittals from the How Group
included responses to the directives in Order No. 889-A, as well as
requests for clarification and suggestions for additional changes to
the S&CP Document based on business experience under OASIS.
---------------------------------------------------------------------------
In Order No. 889-A, we determined that any ``negotiation'' between
a transmission provider and a potential transmission customer over
price discounts should take place on the OASIS, visible to all market
participants. We also ordered some minor revisions to the OASIS
regulations,7 and requested that the How Group recommend
certain changes to the S&CP Document consistent with the determinations
we made in Order No. 888-A.8 We made a request to the How
Group to propose any conforming changes that might be necessary to the
S&CP Document by June 2, 1997, and to inform the Commission of the
earliest date by which the industry could meet our transmission service
negotiation and price discount disclosure requirements during Phase I.
---------------------------------------------------------------------------
\7\ The minor revisions involved corrections of examples,
typographical errors, out-of-date cross references, and similar
changes.
\8\ Consistent with this finding, we made a request to the How
Group to make recommendations on eliminating any references in the
S&CP Document (Version 1.1) pertaining to masking the identities of
parties to the transmission transaction (e.g., at Sec. 4.3.7.b). We
also made a request to the How Group to make recommendations on
revising the templates used for the posted transmission service
offerings (at Sec. 4.3.2), the status of transmission service
requests (at Sec. 4.3.7), and the status of ancillary service
requests (at Sec. 4.3.9) to include: (1) the transmission provider's
transmission and ancillary services maximum (ceiling) rates; (2) the
transmission provider's offering price; (3) the price requested by
the customer; and (4) the details of the negotiated transaction. See
Order No. 889-A, FERC Stats. & Regs. para. 31,049 at 30,568.
---------------------------------------------------------------------------
On June 27, 1997, the How Group proposed interim measures to allow
on-line transmission service negotiation and posting of price discounts
on currently configured Phase I OASIS nodes pending development of a
more satisfactory method.
The How Group also sought clarification of the Commission's stated
intention regarding source and sink 9 disclosure in Order
No. 889-A. In that order, we deleted from the OASIS regulations
provisions permitting transmission customers to request that
transmission providers posting transmission and ancillary service
requests and responses under Sec. 37.6(e) temporarily mask the
identities of the parties to the transaction during and after
negotiations for transmission service.10 The How Group asked
if this meant that the source and sink information routinely provided
by potential transmission customers and reported on OASIS transmission
service request templates was also to be divulged. In addition, the How
Group requested clarification as to whether a transmission price
``discount'' as used in Order No. 889-A refers to any price below the
ceiling price.
---------------------------------------------------------------------------
\9\ As we explain further below, depending on the requirements
of the transmission provider, source and sink information,
specifying the location of the generator(s) and the location of the
ultimate load, may either refer to control areas in which the
generation or load are located, or to specific generator or load
busses.
\10\ The relevant and now deleted OASIS regulations, at
Secs. 37.6(e)(1)(iii) and 37.6(e)(3)(i), respectively, read:
``The identify of the parties will be masked--if requested--
during the negotiating period and for 30 days from the date when the
request was accepted, denied or withdrawn.
When any transaction is curtailed or interrupted, the
curtailment or interruption must be posted (with the identities of
the parties masked as required in Sec. 37.6(e)(1)(iii)) and must
state the reason why the transaction could not be continued or
completed. ''
---------------------------------------------------------------------------
On July 15, 1997, we issued a notice concerning the How Group's
June 27 filing and invited public comment on the request for
clarification of the Commission's masking requirements, the proposed
interim measures for on-line transmission service negotiations, and the
posting of transmission price discounts. The 13 comments we received
are referred to herein as ``Comments on How Group's June 27
letter''.11
---------------------------------------------------------------------------
\11\ Comments on the June 27, 1997 letter were filed by APPA,
CILCO, CCEM, Commonwealth Edison, CPEX, Electric Clearinghouse
(jointly with PECO Energy), EPSA, Florida Power Corp, NRECA, NYSEG,
PJM, and Southern (on behalf of Alabama Power, Georgia Power, Gulf
Power, Mississippi Power, and Savannah). The How Group also filed
comments, on September 22, 1997, which included proposed revisions
to the S&CP Document to accommodate its proposed interim procedures
for on-line transmission service negotiations and the posting of
transmission price discounts.
---------------------------------------------------------------------------
On August 12, 1997, the How Group submitted an updated revised S&CP
Document (Phase IA S&CP Document) to fully implement our transmission
price discount negotiation policy and the minor revisions enumerated in
Order No. 889-A.12 In addition to replacing the How Group's
interim measures with more comprehensive procedures, the Phase IA S&CP
Document incorporates several proposals prompted by the industry's
experience in doing business using OASIS. The How Group proposes
implementation six months after approval by the Commission, in order to
allow four months for standards and protocol development and beta
testing and two months for training and full scale testing.
---------------------------------------------------------------------------
\12\ The How Group submitted a preliminary draft version of this
proposal on July 9, 1997. Further additions, clarifications and
corrections to the August 12, 1997 filing, were submitted on
September 23, 1997.
---------------------------------------------------------------------------
On August 29, 1997, we issued a notice inviting public comment on
the August 12 submittal. Four comments
[[Page 38886]]
were filed and are referred to herein as ``Comments on Phase
IA''.13
---------------------------------------------------------------------------
\13\ Comments on the How Group's Phase IA submittal were filed
by AEP, How Group/Commercial Practices Group, PECO, and Southern.
The How Group/Commercial Practices Group comments included the
September 23, 1997 revision of the Phase IA S&CP Document
incorporating clarifications and minor corrections.
In addition, on April 3, April 9, April 10, and April 27, 1998,
the How Group submitted a series of corrections and revisions to its
OASIS Phase IA submittal incorporating various clarifications and
minor corrections to the S&CP Document. Each successive submittal
superseded all pending earlier submittals. We issued a notice of the
April 10, 1998 submittal and not of those earlier submittals that it
superseded (the April 27 corrections were submitted as comments on
the April 10, 1998 submittal). We expected to act on the latest
corrections of the How Group in this order. However, with so many
revisions, we are uncertain that all errors have been identified. We
therefore invite the How Group to file with the Commission a revised
Phase IA submittal, within 21 days of the date of issuance of this
order, in WordPerfect 6.1 format, that to the greatest extent
possible identifies all needed corrections to the S&CP Document. We
request that the transmittal letter for this submittal provide a
complete explanation of all revisions and why they are being
proposed. We also request that the submittal contain both a clean
version and a redline/strikeout version showing changes between that
version and the one being issued in this order. We will issue a
public notice when we these documents are filed and will take action
on the How Group's recommendations shortly thereafter.
---------------------------------------------------------------------------
II. Discussion
A. Overview
In this order, we: (1) conclude that the source and sink
information reported on OASIS transmission service request templates
should be unmasked at the time when a transmission provider updates the
transmission reservation posting to show the customer's confirmation
that it wishes to finalize the transaction; (2) require modifications
to the operative language in the existing S&CP Document (Version 1.1)
to incorporate our findings on unmasking source and sink information
(to become effective on January 1, 1999) and on proposed interim
measures (to become effective 60 days from the date of publication of
this order in the Federal Register; and (3) adopt, with the revisions
discussed below, the Phase IA S&CP Document (as corrected by the How
Group in its September 23, 1997 submittal), as Version 1.2, to become
effective on December 1, 1998. For clarity, we address the issues
raised by the various How Group submittals and related public comments
on an issue-by-issue basis.
B. Masking of Source and Sink Related Information
The Commission has been asked to decide whether certain information
routinely provided by potential transmission customers, which pertains
to the location of the generator(s) (source) and the location of the
ultimate load (sink) [collectively, source and sink information] should
be made publicly available (by a posting on the OASIS) or should be
kept confidential (and made available only to transmission system
operators). This information, which helps define the transmission
service being requested,\14\ is submitted to the transmission provider
by the potential transmission customer when it completes the
TRANSREQUEST template as part of its initial request for transmission
service.
---------------------------------------------------------------------------
\14\ Source and sink information for point-to-point transmission
service describes the location of the generators and the ultimate
load in an electric system sense, and does not necessarily identify
sellers and buyers by name. In accordance with the convention of the
transmission provider under its individual Open Access Tariff (the
Pro Forma Tariff allowed each transmission provider to determine
this for itself in its Open Access Tariff filing) this source and
sink information may routinely include only the identities of the
respective control areas (e.g., in the case of point-to-point
transmission across a transmission provider's system, the point of
receipt is identified as a control area and the point of delivery is
similarly identified), or it may include the identities of the
respective bus bars of the particular generators and loads (e.g., in
the case of transmission within, out of or into a transmission
provider's transmission system). See, the Data Element Dictionary,
accompanying the S&CP Document that, for template purposes, defines
``source'' as ``[t]he area in which the SOURCE is located'' and
``sink'' as ``[t]he area in which the SINK is located.''
The source and sink information here at issue is the source and
sink information reported on OASIS templates. We are not addressing,
and not requiring the disclosure of, information collected from
customers as part of a complete application for transmission service
under the Pro Forma Tariff, including information on whether the
requested transmission service is feasible (e.g., the NERC
``tagging'' information that might accompany the scheduling of
transmission service). See Coalition Against Private Tariffs, and
Western Resources, Inc., 83 FERC para. 61,015 (1998), reh'g pending
(CAPT). CAPT is further discussed infra at notes 47, 74, and 76.
---------------------------------------------------------------------------
Under the current S&CP Document, the source and sink information
becomes an element of the transmission provider's response to the
potential transmission customer's query on the status of its pending
service request.\15\ However, since such information might be used to
infer the identifies of the power supplier and the power purchaser
associated with a pending transmission service request, historically
this element of the response has been masked. In connection with the
masking of certain other information, in Order No. 889-A, we decided to
delete the temporary masking option provisions in our OASIS regulations
(formerly found in Sec. 37.6(e)(1)(iii) and Sec. 37.6(e)(3)(i), see
supra note 10) applicable to the identities of the parties to the
transmission transaction (i.e., the transmission provider and the
potential transmission customer), since our price discount policy calls
for the identities of the parties negotiating the discount to be made
public during the negotiation period.\16\ Accordingly, we asked the How
Group to eliminate any references in the S&CP Document to the masking
of the identities of transaction parties.\17\ We reaffirmed this
decision in Order No. 889-B.\18\
---------------------------------------------------------------------------
\15\ See also ``service request'' transaction templates at
Sec. 4.3.5 of the S&CP Document.
\16\ Order No. 889-A, FERC Stats. & Regs. at 30,569-70.
\17\ Id. The How Group made this deletion in its August 12,
1997, Phase IA filing.
\18\ Order No. 889-B, 81 FERC at 62,175.
---------------------------------------------------------------------------
In its June 27, 1997, submittal, the How Group asks us to clarify
whether Order No. 889-A intended to require the unmasking of the source
and sink information posted on the TRANSSTATUS and other templates
covered by Sec. 4.3.5b of the S&CP Document. Although the How Group
prepared and provided a summary of the positions of transmission
providers and transmission customers on this issue,\19\ we invited
further public comments on the matter.\20\
---------------------------------------------------------------------------
\19\ In its June 27, 1997 letter, the How Group summarized the
positions of interest groups as follows:
Transmission Providers generally do not have a
preference on this issue, although it is technically easier for them
if there is no masking on OASIS at all.
Transmission customers involved in merchant activities
strongly support having source and sink identity masked from
competitors indefinitely or for as long as possible because they
consider this information to be business sensitive.
\20\ The Commission invited comments on: (1) why some parties
consider this information to be business sensitive or confidential
while others do not; (2) whether public access to this information
might harm competition and reduce efficiency, and if so, why; (3)
whether, in the event that source and sink information continues to
be masked, competitors will be able to accurately infer this
information from other sources; and (4) the implications of
unmasking for contract path and flow-based pricing regimes for
reserving transmission capability.
---------------------------------------------------------------------------
Comments
1. Business Sensitivity and Competitive Effect. It is not clear
that all commenters mean the same thing by source and sink. Some appear
to refer to the exact location of the generation and load, while others
appear to refer to the control area, which may cover a much broader
geographic area. With regard to the impact that unmasking of source and
sink information may have on competition, Commonwealth Edison, CCEM,
EPSA, and PECO Energy predict that unmasking will result in the
elimination of the role that power marketers play in electricity
markets in matching the needs of power suppliers
[[Page 38887]]
to sell their generation output with the needs of power purchasers to
meet their loads.21 They posit that once the location of the
generating facility (source) and the location of the load ultimately
served (sink) for each point-to-point transmission service transaction
is made publicly available, such information will be used by each party
(i.e., the power supplier and the power purchaser) to match up their
respective needs and deal directly with each other, if possible, to
their mutual advantage and to avoid the power marketer's mark-up.
---------------------------------------------------------------------------
\21\ EPSA Comments on How Group's June 27 letter at p. 4; PECO
Energy Comments on How Group's June 27 letter at p. 4; Commonwealth
Edison Comments on How Group's June 27 letter at p. 2; and CCEM
Comments on How Group's June 27 letter at p. 7.
---------------------------------------------------------------------------
Florida Power Corp believes that unmasking source and sink
information will eliminate some opportunities for marketers, if this
information is made publicly available when transmission services are
reserved, because power suppliers and power purchasers will then have
time to negotiate directly.22
---------------------------------------------------------------------------
\22\ Florida Power Corp Comments on How Group's June 27 letter
at pp. 1-2.
---------------------------------------------------------------------------
APPA points to the technical burden that masking efforts place on
transmission providers.23 It further argues that the bypass
of power marketers that might be caused by unmasking is actually an
efficient outcome, if all that unmasking adds to the overall
transaction is the possibility of direct matching of the power supplier
and the power purchaser. APPA asserts that those entities warning that
the unmasking of source and sink information will cause harm to power
marketers are really confusing a threat of private harm with societal
harm. In its view, making source and sink information publicly
available would serve the interests of ultimate customers.24
---------------------------------------------------------------------------
\23\ APPA Comments on How Group's June 27 letter at p. 1.
\24\ APPA Comments on How Group's June 27 letter at p. 3.
---------------------------------------------------------------------------
PJM sees no reason to mask source and sink information. It believes
that providing this information to all market participants will
increase both competition and the overall efficiency of the
market.25 NYSEG shares the view that electricity markets may
become more efficient with more transmission information made available
on a non-discriminatory basis.26
---------------------------------------------------------------------------
\25\ PJM Comments on How Group's June 27 letter at p. 1.
\26\ NYSEG Comments on How Group's June 27 letter at p. 2.
---------------------------------------------------------------------------
Southern suggests that the Commission should not unmask source and
sink information unless it has a strong policy reason to do
so.27 Both EPSA and PECO Energy acknowledge the apparent
benefit of unmasking source and sink information, but contend that such
benefits will not be realized in practice, especially at this early
stage when competitive electricity markets are still
evolving.28 They also argue that unmasking source and sink
information would result in the loss of significant benefits they claim
power marketers now bring to electricity markets, including liquidity,
risk management, and creativity in meeting the unique needs of power
suppliers and power purchasers.29 EPSA foresees the
competitiveness of electricity markets being undermined by unmasking,
with markets eventually returning to monopoly power suppliers and
captive power purchasers.30 CPEX also sees unmasking as a
serious threat to competitive electricity markets.31
---------------------------------------------------------------------------
\27\ Southern Comments on How Group's June 27 letter at p. 4.
\28\ EPSA Comments on How Group's June 27 letter at p. 4 and
PECO Energy Comments on How Group's June 27 letter at p. 3.
\29\ EPSA Comments on How Group's June 27 letter at p. 4 and
PECO Energy Comments on How Group's June 27 letter at p. 4.
\30\ EPSA Comments on How Group's June 27 letter at p. 4.
\31\ CPEX Comments on How Group's June 27 letter at pp. 3-4.
---------------------------------------------------------------------------
CCEM makes the commercial business argument that unmasking will
compel power marketers to give up the benefits that they provide
without being compensated.32 It further argues that the
threat of after-the-fact audits should be sufficient to discourage
instances of undue discrimination in the provision of transmission
services and that unmasking is unnecessary for this purpose.
---------------------------------------------------------------------------
\32\ CCEM Comments on How Group's June 27 letter at p. 4.
---------------------------------------------------------------------------
With regard to more improved utilization of transmission systems,
NYSEG asserts that unmasking will allow all transmission users to gauge
what impact a given transmission service transaction will have on the
transmission provider's system.33 NRECA suggests unmasking
will provide transmission users with a better idea of the planned and
scheduled uses of the transmission system and what additional
transmission capacity is available. While it supports making source and
sink information available at the time when transmission providers and
potential transmission customers finalize reservations and energy
schedules, NRECA opposes unmasking during the period when transmission
reservation requests and the associated off-OASIS energy schedule
requests are still pending.34 Commonwealth Edison sees any
enhancement of transmission system capacity analysis by transmission
customers resulting from the disclosure of source and sink information,
as being only theoretical. It asserts that postings of ``available
transmission capacity'' (ATC) provide sufficient information for
customers to analyze the impacts that various transmission transactions
may have on the transmission system and its users.35
---------------------------------------------------------------------------
\33\ NYSEG Comments on How Group's June 27 letter at p. 1.
\34\ NRECA Comments on How Group's June 27 letter at pp. 1-2.
\35\ Commonwealth Edison Comments on How Group's June 27 letter
at p. 2.
---------------------------------------------------------------------------
2. Other Information Sources and the Need for Source and Sink
Information. With regard to whether similar information might be
available elsewhere, which would allow the identity of the power
supplier and the power purchaser associated with a given transmission
transaction to be inferred even if masking is continued, Commonwealth
Edison and Florida Power Corp opine that it would be extremely
difficult to bypass power marketers by obtaining similar information
from other sources.36 NRECA contends that source and sink
information will be available from the NERC transaction information
system or the tagging form.37 PECO Energy and Commonwealth
Edison believe that unmasking should not be viewed as a reliability
matter.38
---------------------------------------------------------------------------
\36\ Commonwealth Edison Comments on How Group's June 27 letter
at p. 3 and Florida Power Corp Comments on How Group's June 27
letter at p. 3.
\37\ NRECA Comments on How Group's June 27 letter at pp. 1-2.
\38\ PECO Energy Comments on How Group's June 27 letter at p. 2
and Commonwealth Edison Comments on How Group's June 27 letter at p.
4.
---------------------------------------------------------------------------
Some commenters question the underlying need for source and sink
information, even if it is not made publicly available. CPEX asserts
that requiring source and sink information is an unnecessary burden on
merchants and that the only information that system operators need to
assure transmission reliability is information on power being sent and
received through their control areas.39 In CPEX's view, this
is sufficiently covered by ATC without need for specific information on
the source and the sink. CPEX further claims that transmission
curtailment is only infrequently needed and, when it is, it is
implemented by shifting among alternative generation sources without
reliance on source and sink information. APPA, however,
[[Page 38888]]
complains that NERC has a policy of treating tagging information as
confidential.40 Finally, EPSA contends that the adverse
competitive impacts of unmasking outweigh the limited benefits of
source and sink information being collected, since the information is
of only marginal relevance in the rare situation when there is a
transmission constraint.41
---------------------------------------------------------------------------
\39\ CPEX Comments on How Group's June 27 letter at pp. 1-3.
\40\ APPA Comments on How Group's June 27 letter at p. 4.
\41\ EPSA Comments on How Group's June 27 letter at pp. 5-6.
---------------------------------------------------------------------------
3. Differing Impacts on Contract Path and Flow-Based Transmission
Pricing Regimes. With regard to whether unmasking source and sink
information affects either a contract path or flow-based transmission
capacity pricing regime,42 PJM sees unmasking making no
difference.43 Florida Power Corp notes that the method of
calculating ATC for transmission service reservation purposes for
either pricing regime is the same and, for this reason, asserts that
neither pricing regime influences the decision of whether this
information should be unmasked.44 Finally, APPA asserts that
source and sink information is essential under both transmission
reservation pricing regimes for determining the potential impact of a
request and all parties should have equal and full knowledge of this
information.45
---------------------------------------------------------------------------
\42\ Flow-based pricing, unlike contract path pricing, may
recognize all of the paths that a given transmission transaction
utilizes. See Order No. 888, FERC Stats. & Regs. at 31,650 n.95.
``[I]n contrast to contract path pricing, flow-based pricing
establishes a price based on the costs of the various parallel paths
actually used when the power flows. Because flow-based pricing can
account for all parallel paths used by the transaction, all
transmission owners with facilities on any of the parallel paths
could be compensated for the transaction.''
\43\ PJM Comments on How Group's June 27 letter at pp. 1-2.
\44\ Florida Power Corp Comments on How Group's June 27 letter
at pp. 3-4.
\45\ APPA Comments on How Group's June 27 letter at p. 5.
---------------------------------------------------------------------------
Commission Conclusion
Initially, we note that this proceeding does not concern whether
the transmission provider should collect source and sink information
from a potential customer seeking point-to-point transmission service.
Point of receipt and point of delivery information is necessary for the
transmission provider and we are not entertaining comments directed at
challenging the necessity to collect this type of information in this
proceeding. Nor does this proceeding concern questions regarding NERC
tagging information.46
---------------------------------------------------------------------------
\46\The Commission, elsewhere, has previously addressed NERC's
tagging requirements. See, CAPT supra note 15.
---------------------------------------------------------------------------
The issue here is whether to unmask, that is, make known to all
parties, point-to-point transmission service source and sink
information now made known to transmission system operators. We are
persuaded that such source and sink information 47 should be
disclosed publicly through an OASIS posting at the time when the
transmission provider updates the OASIS posting to show that a customer
has confirmed its request for point-to-point transmission service. As
we explain below, we believe that disclosure of this information will
foster greater public confidence in the integrity of OASIS systems and
improve the ability of such systems to facilitate open access use of
transmission systems comparable to that enjoyed by the transmission
providers. We also believe that unmasking can be accomplished without
compromising the role that power marketers play in electricity markets.
---------------------------------------------------------------------------
\47\ We earlier defined the source and sink information here at
issue, supra notes 9 and 14.
---------------------------------------------------------------------------
First, the disclosure of source and sink information will provide
wholesale transmission customers and others with useful data for the
after-the-fact evaluation of the accuracy of transmission providers'
OASIS postings of ATC and total transmission capacity (TTC). Second,
disclosure will also provide useful information for discerning any
patterns of undue discrimination in the rendering of or refusals to
provide transmission services and in price discounting by transmission
providers. Thus, disclosure should encourage accurate postings and fair
treatment leading to better competitive utilization of transmission
systems.
While we acknowledge the potential business sensitivity that power
marketers attach to source and sink information, we believe that
delaying unmasking until the transmission provider updates the
transmission reservation posting to show the customer's confirmation
should allow the power marketer to finalize its arrangements with the
power purchaser and the power seller. Moreover, delaying disclosure
will not result in the public at large losing the benefits that
disclosure offers to all transmission users, including power marketers,
since assessments of the accuracy of posted information and unduly
discriminatory activity based on such information will of necessity be
conducted on an after-the-fact basis. We caution that our overriding
concerns are with the promotion of the overall competitiveness of the
electricity markets and with ensuring openness, confidence, and
nondiscrimination in the use of interstate transmission
facilities.48
---------------------------------------------------------------------------
\48\ Our decision to require that certain potentially sensitive
business information be disclosed is consistent with judicial
directives to focus on the needs of the overall market, instead of
on individual competitors within the market. In Alabama Power
Company v. Federal Power Commission, 511 F.2d 383, 390-391, D.C.
Cir. (1974), we had refused to amend our rule that required affected
utilities to publicly disclose their monthly Form No. 423 reports of
fuel purchases. The court considered various arguments to the effect
that, on the one hand, ``disclosure of information would lead to
bargaining disadvantages in future fuel contract negotiations'' (511
F.2d at 390), and on the other hand, any bargaining disadvantage as
a result of disclosure would merely reflect the removal of
information imperfections in an otherwise competitive market thereby
facilitating efficient allocation of resources. [Id.]
Notably, the court found that,
``a sudden improvement in the availability of information may
deprive a buyer of an advantage he enjoyed when, under more
imperfect dissemination, he exploited a seller's ignorance of the
market price. * * * Generally, however, laws and practices to
safeguard competition assume that its prime benefits do not depend
on secrecy of agreements reached in the market. [Id. at 391,
n.13.]''
---------------------------------------------------------------------------
We thus require that transmission providers unmask the source and
sink information that is posted on TRANSSTATUS and other templates at
the time when a request status posting is updated by the transmission
provider to show that the customer has confirmed, in response to the
transmission provider's acceptance of its offer, that it still wants to
complete the transaction and purchase transmission service.
Accordingly, we order corresponding revisions to be made to the masking
requirements of the S&CP Document.49 However, in recognition
of the concerns expressed in this proceeding regarding the potential
business sensitivity of source and sink information and the somewhat
limited experience the Commission has had with the OASIS, we determine
it is appropriate to delay the implementation of these revisions for
seven months. This will permit competitive electric markets additional
time to develop. Therefore, these revisions are to become effective on
January 1, 1999.
---------------------------------------------------------------------------
\49\ We are revising the operative statement in Sec. 4.3.7.2 of
the S&CP Document (Version 1.1) that reads ``[o]ther fields, such as
SOURCE and SINK, may be masked to comply with FERC regulations and
Primary Provider tariff'' to read as follows:
``Transmission Providers shall make source and sink information
available at the time the request status posting is updated to show
that a transmission request is confirmed.''
---------------------------------------------------------------------------
Our decision to unmask source and sink information is consistent
with
[[Page 38889]]
sections 17.2 and 18.2 of the Pro Forma Tariff.50 These
sections provide that a transmission provider, unless otherwise ordered
to do so, is obligated to treat confidentially information that is
supplied as part of a Completed Application for transmission service
pertaining to the location of the generator and the location of load
ultimately served. We herein find that the obligation in the Pro Forma
Tariff to treat such information confidentially does not contradict the
requirement we are establishing in this order to unmask the source and
sink information reported on the TRANSSTATUS and other S&CP Document
templates at the time when the transmission provider posts on the OASIS
that the customer confirms that it wants to complete the transaction.
As noted above, supra note 50, the Pro Forma Tariff provides that
transmission providers are to keep certain information on source and
sink confidential at the request of a transmission customer, except in
specified circumstances, which include a regulatory order requiring
disclosure. In this regulatory order, we make just such an exception.
Accordingly, the requirement in this order to disclose certain source
and sink information is consistent with the requirements of the Pro
Forma Tariff.
---------------------------------------------------------------------------
\50\ Section 17.2(iv) of the Pro Forma Tariff (Stats. & Regs.,
Regulations Preambles at 30,522) reads:
``The location of the generating facility(ies) supplying the
capacity and energy and the location of the load ultimately served
by the capacity and energy transmitted. The Transmission Provider
will treat this information as confidential except to the extent
that disclosure of this information is required by this Tariff, by
regulatory or judicial order, for reliability purposes pursuant to
Good Utility Practice or pursuant to RTG transmission information
sharing requirements. The Transmission Provider shall treat this
information consistent with the standards of conduct contained in
Part 37 of the Commission's regulations.
Section 18.2(vii) of the Pro Forma Tariff (Stats. & Regs.,
Regulations Preambles at 30,524) reads in relevant part:
``The Transmission Provider will treat this information in (vi)
and (vii) as confidential at the request of the Transmission
Customer except to the extent that disclosure of this information is
required by this Tariff, by regulatory or judicial order, for
reliability purposes pursuant to Good Utility Practice, or pursuant
to RTG transmission information sharing agreements. The Transmission
Provider shall treat this information consistent with the standards
of conduct contained in Part 37 of the Commission's regulations.''
---------------------------------------------------------------------------
C. Proposed Interim Procedures To Achieve On-line Price Negotiation and
Disclosure of Discounts in Phase I OASIS Until Phase IA Changes Are
Implemented
The How Group's proposed interim procedures contain two separate
components. Under the first, transmission service negotiations would be
accomplished by allowing a potential transmission customer to make a
bid by modifying the offered transmission price in the price field of
the TRANSREQUEST template.51 The transmission provider would
then respond to the bid price by using the TRANSSTATUS template to
notify the potential customer of whether the bid was accepted or
rejected. This modification of the price field would require only a
minor change to most OASIS nodes.
---------------------------------------------------------------------------
\51\ We noted in Order No. 889-A, FERC Stats. & Regs. at 30,551
and n.12, that ``negotiation'' would be considered to have taken
place only if the transmission provider or transmission customer
seeks prices below the ceiling prices set forth in the Order No. 888
Pro Forma Tariff.
---------------------------------------------------------------------------
The second proposed interim procedure would create a new category
(``discounts'') in the MESSAGE template to announce agreed-upon
transmission service price discounts. A price discount for a non-
standard transmission related service, such as weekly service beginning
on a Wednesday at 2:00 p.m., would be reported only in the MESSAGE
template.
The How Group requested that the industry be given two months to
test these interim modifications to OASIS templates and implement the
interim measures. While maintaining that its interim procedures are a
somewhat cumbersome method to implement on-line transmission service
negotiations, the How Group contends that the interim measures will
allow negotiations to proceed on the OASIS while a more satisfactory
method is developed.
Comments
CCEM contends that on-line negotiation of transmission prices is
not feasible at this time because the Internet-based OASIS cannot
currently accommodate the speed at which negotiation should comfortably
take place. It argues that the interim on-line negotiation process will
be so cumbersome that transmission providers will lose interest in
price discounting.52 CCEM also sees the disclosure of
transmission price discounts raising business sensitivity concerns and
suggests that real time discount price disclosure is not the only means
available to prevent unduly discriminatory treatment of transmission
customers. As an alternative, CCEM suggests that transmission service
negotiations proceed off-OASIS through a process that would rely on
phone or facsimile communication arrangements between transmission
providers and potential transmission customers.53 Under
CCEM's proposal, whenever a transmission price discount is agreed upon,
the availability of the price discount would be broadcast and
disseminated on-line over OASIS (within 12 hours in the case of an
affiliated customer and within 15 days in the case of a non-affiliated
customer).54
---------------------------------------------------------------------------
\52\ CCEM Comments on Interim Measures at pp. 11-12.
\53\ CCEM Comments on Interim Measures at p. 11.
\54\ Id.
---------------------------------------------------------------------------
Commonwealth Edison argues that transmission service negotiations
off-OASIS should continue, based on concerns about whether price
negotiations could be conducted successfully through present OASIS
nodes under the interim measures, given the many steps, the amount of
time involved, and the OASIS capacity needed to handle the increased
volume of the related communications.55
---------------------------------------------------------------------------
\55\ Commonwealth Edison Comments on Interim Measures at pp. 4-
5.
---------------------------------------------------------------------------
While supporting electronic negotiation of transmission prices, and
noting that the NYPP OASIS node could implement the interim measures
now, NYSEG also prefers to wait until a real-time or faster Internet-
based OASIS system is developed. NYSEG suggests that, during the
interim, transmission negotiations rely on recorded telephone calls
with any agreed-upon price discounts posted on the OASIS within thirty
minutes of the completion of the negotiations.
PJM notes that no changes will be required to the PJM OASIS to
implement the How Group's interim measures. Southern, however, cautions
that OASIS systems are still in the early stages of development and
that requiring the capability for on-line negotiation of transmission
price discounts, at this critical stage, would add further complexity
to the design of OASIS nodes that could slow down the transmission
reservation process and actually could impede the growth of more robust
power trading.56
---------------------------------------------------------------------------
\56\ Southern Comments on Interim Measures at p. 2.
---------------------------------------------------------------------------
Florida Power Corp agrees that the proposed interim measures could
be implemented through modification of existing OASIS templates, but
stresses that price negotiations will be very cumbersome and not
practical, especially for short-term transactions. It suggests that
negotiations be conducted by telephone calls, with the results
immediately posted on OASIS.57
---------------------------------------------------------------------------
\57\ Florida Power Corp Comments on Interim Measures at pp. 4-5.
---------------------------------------------------------------------------
[[Page 38890]]
NRECA asserts that the interim measures will work effectively only
if transmission providers respond in a timely manner to transmission
customer requests for price discounts. However, it is willing to accept
the interim measures even though they constitute a retrofit and would
have developed differently if considered in the initial OASIS design
stage.58
---------------------------------------------------------------------------
\58\ NRECA Comments on Interim Measures at p. 3. Although NRECA
argues that ``timely'' responses are needed, it seeks no revisions
to the timetables for posting in 18 CFR 37.6. This issue is also
raised by PECO in their comments to Phase IA.
---------------------------------------------------------------------------
PECO Energy argues that transmission negotiations off-OASIS should
continue, since the majority of transmission providers may not be able
to successfully implement the software changes necessary for on-line
negotiation of transmission prices over OASIS. PECO opposes mandatory
interim measures for on-line negotiation until OASIS is greatly
improved.59 However, it believes that price discounts should
be disclosed when offered to affiliates and non-affiliates alike,
following the completion of the negotiations.
---------------------------------------------------------------------------
\59\ PECO Energy Comments on Interim Measures at p. 7.
---------------------------------------------------------------------------
Commission Conclusion
As we stated in Order No. 889-A,60 the objective of the
interim procedures is to implement our Order No. 888-A on-line
transmission price negotiation policy as soon as possible through
OASIS, so we can improve the competitiveness of the electricity markets
while the industry develops a more sophisticated ``Phase IA'' approach.
Keeping this in mind, we are adopting the first of the How Group's two
proposed interim measures (involving modifications to the price field
of the TRANSREQUEST template) because it appears that this interim
modification can be easily made. We are not adopting the How Group's
second proposal (involving a new ``discounts'' flag in the MESSAGE
template) because this revision is more complex and we wish to keep the
burden of implementing the interim procedures to a
minimum.61 Under this limited interim procedure, wherein we
merely allow the price field to be modified,62 a potential
transmission service customer will be able to request discounts via
OASIS, but only on posted transmission service offerings. No commenter
has provided persuasive evidence that the How Group's proposal cannot
be implemented within the How Group's proposed time frame.
---------------------------------------------------------------------------
\60\ Order No. 889-A, FERC Stats. & Regs. at 30,551.
\61\ We note, however, that in section II.G infra, we accept the
How Group's proposal to add a negotiation flag in the TRANSSTATUS
template to enable customers to search for discounts, as part of the
Phase IA S&CP Document revisions.
\62\ This modification is more fully explained in note 63,
infra.
---------------------------------------------------------------------------
Relying on the How Group's interim proposal, we direct changes to
the operative language of the current S&CP Document to allow a
potential transmission customer to modify the price field when
submitting a request to purchase transmission service using the
TRANSREQUEST template.63 If the customer's bid is approved,
the provider will respond by posting the message ``accepted'' in the
TRANSSTATUS template. If the customer's bid is not accepted, then the
provider will respond by posting the message ``denied.''
---------------------------------------------------------------------------
\63\ In the interim, until the revised S&CP Document Version 1.2
(see Attachment 2) becomes effective, we will modify the operative
language of S&CP Document Version 1.1, as proposed in the How
Group's June 27, 1997 letter with some minor clarifications, through
the addition of the following language to Sec. 4.3.7:
``For on-line price negotiation the customer can modify the
price field when submitting a request to purchase transmission
service using the TRANSREQUEST template. The provider response in
the TRANSSTATUS template will either indicate ``accepted'' if the
bid is approved, or ``denied'' if the bid is not accepted. The
reason for denial would be shown in the comments field. The
TRANSSTATUS template would retain the customer's bid price as a
permanent record, whether accepted or not. If the request is denied
for price reasons, the customer could repeat the process by
submitting a new request with a different price bid. If a discount
is given on a posted product, it is also required that the
transmission provider change the posted offer price to match the
discounted price for the service, for all unconstrained paths to the
same point of delivery (POD) and for the same time period.''
This insertion would precede ``a. Customer Capacity Purchase
Request'' in Sec. 4.3.7 of the S&CP Document. We are making this
change through the issuance of this order and not through the
issuance of an updated S&CP Document because it is to be in effect
for only a limited time.
---------------------------------------------------------------------------
We require implementation of this directive by September 11, 1998
so that discounts can be requested on-line without waiting for the
industry to implement comprehensive changes in Phase IA OASIS.
We believe the benefits of fostering on-line discounting as soon as
possible in this limited fashion outweigh the problems that may result
from the use of a somewhat cumbersome process and find this preferable
to waiting until OASIS Phase IA improvements can be implemented before
implementing on-line discounting. As to any business sensitivity
concerns over our decision to make price negotiation visible on OASIS,
the time to raise these concerns was in the rehearing of Order No. 889-
A and not at this compliance stage.
D. How Group Proposals To Revise the Phase IA S&CP Document
Requirements
The How Group's proposed longer term revisions incorporated in a
Phase IA S&CP Document (Version 1.2) include both the changes we
directed in Order No. 889-A and other changes prompted by the
industry's experience with operating OASIS sites.64 Except
as discussed below, we find these modifications to the S&CP Document to
be acceptable and direct its revision with minor editorial changes to
correct typographic errors, enumeration of sections, and other
nonsubstantive changes.65 Additionally, interested persons
filed comments on certain of the proposed revisions to the S&CP
Document, which we also address below.
---------------------------------------------------------------------------
\64\ Changes directed by the Commission include: (1) provision
for on-line interactive negotiation (such as the addition of new
data elements for price offered, price bid, ceiling price); (2)
provision for linking ancillary services to transmission services;
(3) provision for identification of a reservation made by an
affiliated merchant; (4) provision for posting personnel transfers;
(5) provision for posting incidents in which the provider exercises
discretion in the application of tariffs; and (6) removal of all
references in the S&CP Document to masking.
Improvements suggested by industry's experience include: (1)
automatic notification of customers (dynamic notification) when the
status of a reservation request has changed (to speed up the process
of negotiating by reducing the customer's need to check an OASIS
node repeatedly for the status of a pending request); (2) merging
all transmission service offering templates into a single template
(to simplify doing business); (3) further standardization of
transmission service product names and identification of their
attributes; (4) introduction of ``sliding windows of time'' allowing
purchases of blocks of service (running 60 minutes, 24 hours, 7
days, or 30 days) on a non-calendar period basis; (5) introduction
of ``capacity profiles'' reservations (allowing for a single
reservation for monthly service to set different levels of reserved
capacity for each day thereof); and (6) a new template for nonfirm
secondary service over alternate points of receipt and delivery
(provides additional support for secondary transmission service).
\65\ In Attachment 3 to this order, we show all the changes that
we have made and direct to the How Group's September 23, 1997,
submittal in redline and strikeout fonts. In Attachment 2, we
provide the revised document without redline and strikeout fonts.
Attachments 2 and 3 will be posted on the Commission Issuance
Posting System (CIPS) and may be reviewed in the Commission's Public
Reference Room during normal business hours. Details about accessing
CIPS are given in the supplementary information preceding this
order, supra at ii.
---------------------------------------------------------------------------
1. Comments on Preconfirmed Reservations
In connection with transmission service negotiations, Section
4.2.10.1(a) of the How Group's proposed Phase IA S&CP Document
indicates that OASIS shall set OFFER__PRICE equal to BID__PRICE in the
case of
[[Page 38891]]
``preconfirmed'' transmission reservation requests. AEP states that
this proposal should satisfy the restriction/requirement that
BID__PRICE be equal to OFFER__PRICE for any reservation to be
CONFIRMED; 66 however, AEP is concerned that parties to a
preconfirmed transaction using the proposal may inappropriately modify
or unwittingly accept price information. Thus, it requests that we
substitute the following requirement:
---------------------------------------------------------------------------
\66\ AEP Comments on Phase IA at p. 5.
---------------------------------------------------------------------------
Prior to or commensurate with a Seller's setting a preconfirmed
reservation request's STATUS to ACCEPTED (and by implication
CONFIRMED), the Seller must set OFFER__PRICE equal to the value of
the BID__PRICE as established by the Customer on submission of the
request.
Commission Conclusion
The Commission adopts AEP's suggestion and proposed wording for the
Phase IA S&CP Document. It is more specific and thus less subject to
differing interpretations. AEP's proposal clarifies that the setting of
the OFFER__PRICE equal to the BID__PRICE occurs only when the Seller
accepts the preconfirmed request. We remind transmission providers that
our OASIS regulations require that, if discounts are offered, they be
offered to all transmission customers.67
---------------------------------------------------------------------------
\67\ See Order No. 889-A, FERC Stats. & Regs. at 30,568.
---------------------------------------------------------------------------
2. Comments on Linking Ancillary and Transmission Services
The How Group proposes adding Sec. 4.2.12 to conform the S&CP
Document to the revisions directed by Order No. 889-A in connection
with Secs. 37.6(c)(4) and 37.6(e)(1)(iv) of the Commission's OASIS
regulations, which require that transmission service offerings and
transaction status postings identify the associated ancillary services
and ancillary service transaction status.
AEP notes that the Commercial Practices Group white paper
recommendation on the handling of ancillary services during Phase IA,
i.e., that
basic point-to-point transmission service should be requested before
any Ancillary Services to support that basic point-to-point
transmission service are requested
was not incorporated in the How Group's proposal. AEP requests
that the Commission adopt a provision that, for OASIS Phase IA, all
ancillary service transactions/reservations are subordinate to and
in support of a single transmission service reservation.
AEP argues that adoption of this provision would significantly simplify
the implementation of the How Group's proposal. AEP contends that, if
one considers pre-arrangement for Operating Reserve-Spinning Reserve
from a third party ancillary service provider, that service provider
will require notification that some or all of that service is
supporting one or more transmission reservations made at some point in
the future as those reservations are confirmed. As currently there is
no proposed mechanism to query OASIS for reservations that reference
this pre-arranged ancillary service reservation, AEP questions whether
the third-party supplier market for ancillary services is robust enough
to warrant the significant investment in programming resources needed
to implement the How Group's proposal without such
modification.68
---------------------------------------------------------------------------
\68\ AEP Comments on Phase IA at pp. 5-7.
---------------------------------------------------------------------------
Southern contends that the How Group's proposal to allow
transmission customers to indicate a preferred provider of ancillary
services and indicate which services will be purchased in the future,
injects confusion into the reservation process by giving transmission
customers options inconsistent with the Pro Forma Tariff. It also
asserts that the proposal is unnecessary because the existing ``request
reference'' or ``deal reference'' fields can be used to link ancillary
and transmission services as required by the Commission.69
---------------------------------------------------------------------------
\69\ Southern Comments on Phase IA at pp. 4-5.
---------------------------------------------------------------------------
Commission Conclusion
We believe that AEP's suggestion to limit the flexibility inherent
in the ancillary services linkage proposal reduces the Phase IA
programming necessary to implement the proposal and is a practical
suggestion. Nonetheless, while we adopt its suggestion that requests
for ancillary service be associated with a single transmission service
reservation, we find it unnecessary to completely adopt AEP's
recommendation for the Commission to require that basic point-to-point
transmission service must be requested before any request is made for
supporting ancillary services. This would interfere with customers
attempting to take advantage of certain optional ancillary service
packages transmission providers offer with their transmission service
offerings. Therefore, ancillary services may be requested before,
concurrently with, or subsequent to, the related request for basic
point-to-point transmission service.
We also agree with Southern that it is the Pro Forma Tariff, and
not the OASIS regulations, that controls the minimum ancillary services
that must be offered by a transmission provider. However, the How
Group's Phase IA proposal merely attempts to accommodate the
reservation options that transmission customers may have under a
particular transmission provider's Pro Forma Tariff. To the extent that
Southern has a feasible but simpler approach to handle ancillary
service linkage, we encourage it to pursue its idea with the How Group
to improve Sec. 4.2.12 of the S&CP Document.
3. Comments on Capacity Profiles
The How Group proposes to introduce, in Phase IA, the concept of
capacity profiles for reservations of varying amounts of capacity over
a given service period. For example, a single OASIS transaction would
cover a weekly reservation that incorporates varying daily reservation
levels.
Southern asks for rejection of the capacity profile mechanism,
claiming that OASIS, as it is currently configured, permits
transmission customers to accomplish the same result through the
submissions of multiple requests, each tied to the others through a
common deal reference number supplied by the transmission customer and
that, in any event, the computer systems of transmission providers are
not set up for this process. Southern implies that the capacity profile
reservation mechanism is also not feasible because the Pro Forma Tariff
does not include provisions that allow transmission customers to make
reservations based on capacity profiles.70
---------------------------------------------------------------------------
\70\ Southern Comments on Phase IA at pp. 5-6.
---------------------------------------------------------------------------
AEP questions whether transmission customers should be able to
negotiate the price of the individual hours of a capacity profile. It
claims that the S&CP Document has also defined the templates used to
negotiate the transmission price of the individual hours of a capacity
profile in an inconsistent and ambiguous manner. AEP, therefore,
requests that any reference to pricing information for the individual
hours of capacity profiles be removed.71
---------------------------------------------------------------------------
\71\ AEP Comments on Phase IA at pp. 7-8.
---------------------------------------------------------------------------
Commission Conclusion
The How Group's Phase IA proposal for implementing capacity
profiles in Sec. 4.3.7.1 of the S&CP Document leaves the adoption of
the capacity profile transaction process to the option of each
transmission provider:
[s]upporting ``profiles'' of service, which request different
capacities for different time
[[Page 38892]]
periods within a single request, are at the discretion of the
Primary Provider.72
---------------------------------------------------------------------------
\72\ August 12, 1997 How Group Letter at p. 48.
Accordingly, AEP, Southern, and other transmission providers will be
free to decide whether to implement the capacity reservation profiles
on their individual OASIS nodes within the parameters of the service
offering prescribed by their respective Pro Forma Tariffs. The
revisions to the S&CP Document which we adopt today merely provide a
consistent method to follow by transmission providers in the event they
choose to offer capacity reservation profiles.
4. Comments on Posting of Losses
PECO points out that, while transmission customers must account for
losses when making a transmission reservation, it can be a very time
consuming process for customers to search through the transmission
provider's tariff to determine how losses will be applied on systems
where losses vary from path to path.73 PECO proposes either
that the transmission provider's response to a request for transmission
service via the ``TRANSOFFERING'' template include loss information or,
alternatively, that a table of losses be posted on the OASIS by the
transmission provider.
---------------------------------------------------------------------------
\73\ PECO Comments on Phase IA at p. 2.
---------------------------------------------------------------------------
Commission Conclusion
PECO raises a valid concern. While we encourage transmission
providers to post a table of losses on their OASIS nodes because such
information is useful to transmission customers, we will not require it
at this time because we believe that transmission users would be best
served if loss information were provided in a standardized template.
Therefore, we request that the How Group consider this as part of the
OASIS Phase II process.
5. Revisions to Phase IA S&CP Document Recommended by the How Group and
the Commercial Practices Group
In their joint comments, the How Group/Commercial Practices Group
recommend one change, and several clarifications and minor corrections
to the proposed Phase IA S&CP Document. The change pertains to the
addition of two data elements requiring the establishment of two new
fields (NERC__CURTAILMENT__PRIORITY and OTHER__CURTAILMENT__PRIORITY)
to several templates (TRANSOFFER, TRANSSTATUS, LIST, TRANSSERV,
SCHEDULE, CURTAIL, TRANSSELL, TRANSPOST), to inform transmission
customers about the NERC curtailment priority and other regional
curtailment priority assigned to each transmission service
offering.74 These priorities are set by the transmission
provider, consistent with the tariff on file with the Commission. The
minor changes include enumeration, typographical, sequencing,
identification, and format corrections and fixes.75
---------------------------------------------------------------------------
\74\ While these data elements would inform customers of the
curtailment priorities of NERC and various regional entities,
curtailment priorities for transmission providers that are public
utilities are governed by the applicable Pro Forma Tariff unless the
Commission approves a transmission provider's proposal to revise its
Pro Forma Tariff based on a showing that its revised curtailment
priorities are consistent with or superior to the Pro Forma Tariff.
See CAPT, supra note 14. Absent such an approved tariff revision, to
the extent that a conflict exists between the curtailment priorities
of NERC or another entity and the applicable Pro Forma Tariff, the
Pro Forma Tariff shall govern.
\75\ How Group/Commercial Practices Group Comments on Phase IA
at pp. 1-2.
---------------------------------------------------------------------------
Commission Conclusion
We adopt the new data elements as an option that transmission
providers may display because they provide useful information. However,
we caution that our adoption of a place on the OASIS for these data
elements does not constitute an approval of the NERC or other
curtailment priorities.76 We also adopt the proposed
corrective suggestions for Phase IA purposes because they improve and
help complete the S&CP Document.
---------------------------------------------------------------------------
\76\ As we advised in CAPT supra note 14:
[t]he Commission further encourages the industry to examine
reliability aspects of the Pro Forma Tariff when additional detail
may be required to implement specific reservation, scheduling, and
curtailment procedures and to propose generic improvements to the
Pro Forma Tariff.
Such proposed detail cannot be considered approved by the
Commission by virtue of our approving its display on the OASIS.
---------------------------------------------------------------------------
E. Other Proposed Revisions to the S&CP Document
1. Comments on Standardized Naming of Transmission Paths
AEP raises the issue of the need for consistent naming of point-to-
point transmission paths among transmission providers' systems. It
observes that inconsistent naming of paths among transmission providers
has had a significantly negative impact on transmission customers'
ability to effectively use OASIS to procure needed transmission
services. AEP, therefore, proposes its own naming convention for
transmission paths:
Where a point of receipt and/or delivery (data elements
POINT__OF__RECEIPT and POINT__OF__DELIVERY) represents a NERC
Control Area, the NERC 4 character Control Area acronym shall be
used as the name of that point of receipt and/or delivery.
Where a path (dat[a] element PATH__NAME) represents the
interconnection between two NERC Control Areas, the PATH__NAME shall
be composed of: ``REGION__CODE/PRIMARY__PROVIDER__CODE/PATH__CODE//
''. REGION__CODE and PRIMARY__PROVIDER__CODE are as defined in the
Data Element Dictionary. PATH--CODE shall be composed of the
POINT__OF__RECEIPT followed by the hyphen (-) character and
POINT__OF__DELIVERY, where POINT__OF__RECEIPT and
POINT__OF__DELIVERY are the associated NERC 4 character Control Area
acronyms. OPTIONAL__CODE and SPARE__CODE are null.77
---------------------------------------------------------------------------
\77\ AEP Comments on Phase IA at p. 2.
---------------------------------------------------------------------------
Commission Conclusion
We agree with AEP that a consistent naming convention of paths will
greatly improve the usefulness of Phase IA OASIS. However, in this
instance, we are reluctant to impose a change in a business practice
without giving the industry the opportunity to consider other
possibilities and reach a consensus on the best solution. Since the
Commercial Practices Group has been formed to develop business practice
standards for OASIS, we request that the Commercial Practices Group
propose a consistent naming convention for transmission paths by August
31, 1998.
2. Comments on Reservation Templates
AEP notes that the cumbersome process that transmission customers
must follow in making arrangements for transmission service on OASIS is
made more cumbersome by those transmission providers that require
submission of reservation requests to enter and exit their systems for
``passthrough'' or ``wheeling'' type transactions.78 AEP
suggests that a single reservation request should be sufficient to
cover both entering and existing the transmission system for such
service. AEP asks that we modify the S&CP Document (or the OASIS
regulations) to the extent necessary to enable transmission customers
to rely on a single reservation transaction for wheeling across a
transmission system regardless of whether the particular path is
posted.
---------------------------------------------------------------------------
\78\ AEP Comments on Phase IA at pp. 2-3.
---------------------------------------------------------------------------
Commission Conclusion
AEP is correct that our rules currently do not require postings in
a manner that a allow a single reservation transaction for wheeling
across a transmission system, without a specific advance
[[Page 38893]]
request from a customer that a particular path be posted that way. We
are reluctant to direct such a change at this time because it would
require a redesign of OASIS. However, the current system has sufficient
flexibility to deal with this problem on a case-by-case basis without
the need for the Commission to modify its rules. The OASIS regulations
at Sec. 37.6(b)(1)(i) currently require that transmission providers
post information pertaining to any path requested by a transmission
customer, and transmission providers are free to post additional paths
of commercial interest.79 Thus, if a customer intends to do
business across a system, it can make a request that the transmission
provider post the path as an ``in and out'' path so that a single
reservation can cover transmission passing through the transmission
provider's system.80
---------------------------------------------------------------------------
\79\ 18 CFR 37.6(b)(1)(i).
\80\ Such an approach requires foresight by the customer (or by
the transmission provider). If the customer has not made a request
in advance that the path at issue be posted, then it would not be
posted in time to accommodate the transaction (unless posted at the
request of another customer).
---------------------------------------------------------------------------
We encourage AEP to pursue its idea with the How Group, and to
consider, together with the How Group, what system redesign its
proposal would necessitate, and whether this would be feasible and cost
justified.
3. Comments on Dynamic Notification of Secondary Market Providers
Phase I OASIS nodes do not actively notify a potential transmission
customer of information changes such as the current ATC for a given
path or the status of a pending service request. The OASIS systems are
passive, presenting information that is current only at the time when a
particular OASIS node is queried by the customer. To determine if more
current information is posted, the customer cannot simply ``stay
tuned'' to the site but must continually re-query it. In Order No. 889-
A, we noted the passive nature of Phase I OASIS systems and requested
that the How Group consider adding more active, dynamic capabilities to
OASIS in Phase II.
In its Phase IA submittal, the How Group proposes to add some
dynamic capability to facilitate on-line transmission service
negotiations prior to Phase II, which we are adopting in this
order.81 It proposes that OASIS nodes automatically notify a
customer when the status of a reservation request has changed, from
``pending'' to either ``accepted'' or ``denied.'' This would reduce the
number of steps involved in closing a transmission service deal and
reduce the incidence of unnecessary polling of OASIS nodes for status
checks.82
---------------------------------------------------------------------------
\81\ See supra note 64.
\82\ How Group's August 12, 1997, letter at Attachment 1.
---------------------------------------------------------------------------
AEP notes that a potential competitive problem exists on OASIS that
could be resolved by modifying and extending the How Group's Phase IA
dynamic notification proposal. AEP points out that a host transmission
provider can gain an advantage by programing its own OASIS computer
system to automatically notify it about any customer requests for
transmission service while the host's competitors (e.g., resellers of
capacity on its transmission system (secondary sellers) and sellers of
ancillary services to be used in conjunction with capacity on its
transmission system) would be forced to query the host's OASIS node
repeatedly to learn of any requests for the types of services they
offer.83
---------------------------------------------------------------------------
\83\ Order No. 889, FERC Stats. & Regs. at 31,621-22, requires
transmission providers to post resales of capacity from their
transmission systems, on their OASIS nodes. To prevent transmission
providers from gaining a competitive advantage over resellers,
transmission providers must post such information on the same
display page using the same tables used for their own offerings.
Transmission providers must also provide postings of offers to sell
ancillary services on the same page and in the same format that they
use for their own offerings.
---------------------------------------------------------------------------
AEP believes that extending dynamic notification to secondary
market providers and ancillary service providers would resolve this
competitive problem. It requests that a requirement for such additional
dynamic notification be added to the Phase IA S&CP
Document.84
---------------------------------------------------------------------------
\84\ AEP Comments on Phase IA at pp. 3-4. Specifically, AEP
proposes:
``As an extension of the Company registration information of the
host, domain and port identifiers for dynamic notification of
changes in the Customer's purchase requests, a field should be added
to the Company's registration information that would define/identify
how notification would be delivered to that Company should a
transmission or ancillary purchase request be directed to that
Company as a Seller of a transmission or ancillary service. The
pertinent information would be either a full HTTP protocol URL
defining the protocol, host name, port, path, resource, etc.
information or a ``mailto:'' URL with the appropriate mailbox
string. On receipt of any purchase request directed to that Company
as SELLER via either the ``transrequest'' or ``ancrequest''
templates, or on submission of any change in request STATUS to that
Company as SELLER via either the ``transcust'' or ``anccust''
templates, a notification message formatted as documented for the
delivery of notification to the Customer, shall be formatted and
directed to the Seller.''
---------------------------------------------------------------------------
Commission Conclusion
We agree with AEP that its proposed extension of the dynamic
notification proposal would eliminate a potential competitive problem.
Therefore, we adopt AEP's modified dynamic notification proposal and
accordingly modify Sec. 4.2.8.2--Company Information and
Sec. 4.2.10.3--Dynamic Notification, of the S&CP Document to permit
secondary market and ancillary services providers who wish to be
automatically notified, to identify themselves by merely registering
with the transmission provider.\85\ However, for purposes of Phase IA,
this extension of dynamic notification is required only where the
transmission provider has programmed its computer system for its own
notification. During Phase II, the OASIS nodes of all transmission
providers will be required to have this capability.
---------------------------------------------------------------------------
\85\ We note that AEP's proposed procedure parallels the
registration procedure proposed by the How Group for Phase IA
dynamic notification of transmission customers.
---------------------------------------------------------------------------
4. Comments on Reservation Time Limits
PECO requests the establishment of predetermined deadlines
applicable to all OASIS nodes, by which acceptances by transmission
providers of transmission service requests and confirmation by
transmission customers pertaining to their requests must be made.\86\
It contends that predetermined time limits will enable all parties to
be aware of pertinent deadlines. On this matter, NRECA similarly points
out, as it did for the proposed interim measures, that the proposed
Phase IA transmission price discount procedures will work only if
transmission providers respond to requests for transmission price
discounts in a timely manner.\87\
---------------------------------------------------------------------------
\86\ PECO notes that the Commission has approved at least one
tariff (Wisconsin Electric Power Company, 80 FERC para. 61,299
(1997), reh'g denied (unpublished order dated November 13, 1997))
that permits the transmission provider to set deadlines by which
customers must confirm reservations.
\87\ PECO Comments on Phase IA at p. 3.
---------------------------------------------------------------------------
Commission Conclusion
We note that the Pro Forma Tariff sets the deadlines applicable to
transmission providers and we are not in this order modifying those
deadlines.\88\ Also, in Order No. 889-A, the matter of deadlines
applicable to transmission customers was reserved for resolution in
Phase II due to our reluctance to specify confirmation time limits
without first soliciting the views of representative industry segments.
PECO and NRECA, however, make a compelling argument that consistent
confirmation deadlines among OASIS nodes are needed before
[[Page 38894]]
Phase II. In addition, the Commercial Practices Group is now available
to review this matter and give us its recommendations on how we should
proceed. We, therefore, request that the Commercial Practices Group
examine the development of proposed Phase IA deadlines and make
recommendations to us on this issue by August 31, 1998.
---------------------------------------------------------------------------
\88\ See Order No. 888-A, FERC Stats. & Regs. para. 31,048 at
30,523-24. Section 17.4 of the Pro Forma Tariff gives the deadlines
for a notice of a deficient application, section 17.5 of the Pro
Forma Tariff gives the deadline for a response to a competed
application, and section 18.4 of the Pro Forma Tariff gives the
deadline for a determination of available capability.
---------------------------------------------------------------------------
F. Data Elements in the Templates Are To Be Fixed in Sequence and
Number, and Are Not To Differ Among OASIS Nodes
The How Group asks us to reconsider our Order No. 889-A
clarification that data elements in OASIS templates must be fixed in
sequence and number, and are not to differ from OASIS node to OASIS
node. The How Group contends that this does not permit the introduction
of new fields to existing templates and it stifles OASIS innovation by
transmission providers.
Commission Conclusion
The Commission continues to believe that permitting transmission
providers to reorder and add their own information to OASIS templates
defeats the purpose of standardizing electronic communication across
all OASIS nodes. Standardization of electronic communication across all
OASIS nodes is the underlying principle that permits efficient movement
of power across the grid by making it easier for customers to locate
information in a timely manner across various OASIS nodes. As we have
stated before, when the industry proposes modifications to the
standards, we will continue to order revisions to the S&CP Document,
thus implementing across-the-board changes to the templates for all
OASIS nodes, as necessary.\89\ Moreover, even though we will continue
to be responsive to requests to revise the S&CP Document as warranted,
the proper forum for challenging issues first decided in Order No. 889-
A (such as this one) would have been in a timely request for rehearing
of Order No. 889-A.
---------------------------------------------------------------------------
\89\ Order No. 889-A, FERC Stats. & Regs. at 30,574.
---------------------------------------------------------------------------
G. The Meaning of Disclosure of a Discount Given to a Particular
Customer
The How Group asks the Commission to clarify the definition of what
constitutes a transmission price ``discount.'' The How Group's June 27,
1997 letter states that it understands the Commission's definition to
be any price below the tariff or ceiling price. The August 12, 1997 How
Group letter requests clarification that, for the purpose of requiring
disclosure of any transmission price discount given to a particular
customer, the transmission price discount should be defined as any
negotiated price different from the offer price that has been posted on
the OASIS. The How Group proposes to identify transmission price
discounts in two ways: (1) discounts from the ceiling price and (2)
discounts stemming from negotiations regardless of whether the initial
offer was the ceiling price. All discounts would be identified by
posting the discounted price next to the ceiling price in the offering
templates posted by the transmission provider. Negotiated discounts
would be identified by a negotiation ``flag'' in the TRANSSTATUS
template.\90\ The negotiation ``flag'' would enable searches for
discounts given to particular customers for specific transmission
services, including searches by path, points of receipt and delivery,
etc.\91\
---------------------------------------------------------------------------
\90\ The ``flag'' would identify whether the negotiated
transmission service price is higher or lower than a transmission
provider's offering price. A negotiated price may be higher than the
offering price (not to exceed the ceiling price), for example, as
the result of an auction on a constrained interface.
\91\ How Group Phase II Report at p. 16.
---------------------------------------------------------------------------
Commission Conclusion
We agree with the How Group that, pursuant to our Order No. 888-A
policy, a transmission price discount is present whenever a
transmission price below the tariff or ceiling price is offered or
negotiated by a transmission provider. The proposed use of a
negotiation flag, in addition to the ceiling price and offer and bid
price in the TRANSSTATUS template, meets our requirement to disclose
transmission price discounts, identifying both a negotiated
transmission price discount as well as an initial transmission offer
price positioned below the ceiling price. We incorporate the How
Group's proposal in the revised Phase IA S&CP Document.
H. Date of Implementation for Phase IA Changes
The How Group proposes an implementation date for its proposed
Phase IA changes starting six months after approval by the Commission.
This schedule would provide four months for development and beta
testing and two months for training and full scale testing.
Commission Conclusion
We agree with the How Group that the six-month implementation
schedule is reasonable. Accordingly, we will direct that the Phase IA
changes must be implemented on December 1, 1998.
I. Impact of Phase IA Implementation
Southern posits that the overall goal of Phase I should be to
ensure a reliable core set of transmission service information in a
format that is easy to access and simple to use and that Phase IA will
represent progress only if it has the effect of making OASIS workable
for the majority of market participants.92 Therefore, the
resources of transmission providers and customers should be
concentrated on making day-to-day OASIS operations more effective,
before adding new features to OASIS.93 Southern contends
that the benefits of Phase IA are not worth the risk of market
disruption that is sure to be caused by implementing an interim and
substantially new OASIS. Repeating the point it made with respect to
the proposed interim measures, Southern argues that Phase IA on-line
negotiations may add complexity and will impede rather than accelerate
robust trading of power because it will burden OASIS without increasing
throughput. It adds that linking ancillary services to transmission
services further increases the data entry requirements of the
transmission provider and further increases the data that must be
transferred between the provider and customer.
---------------------------------------------------------------------------
\92\ Southern Comments on Phase IA at pp. 1-6.
\93\ Southern Comments on Phase IA at p. 2.
---------------------------------------------------------------------------
Commission Conclusion
As noted, Southern repeats its contention that interim measures for
on-line negotiations may add complexity and impede rather than
accelerate robust trading of power because it will increase the burden
of using OASIS without increasing its throughput. Nonetheless, the
policies that led to the changes at issue here were adopted by the
Commission in Order No. 889-A after a full review on rehearing of Order
No. 889. The proper forum to challenge the Commission's findings in
Order No. 889-A would have been in a timely request for rehearing of
that order. At this juncture, we are not persuaded to revise our
policies concerning on-line negotiations and ancillary services.
J. Uniform Formats for Organizational Charts and Job Descriptions
In American Electric Power Services Corp., 81 FERC para. 61,332 at
62,512 (1997), order on reh'g and clarification, 82 FERC para. 61,131
at 61,470-71 (1998), the Commission required transmission providers to
post organizational charts and job descriptions on their OASIS
[[Page 38895]]
nodes. Currently, transmission providers use many different software
programs to create and post organizational charts and job descriptions
including, but not limited to, Adobe Systems Incorporated's portable
document format (``PDF''), Microsoft Corporation's ``Word'', and
hypertext marked language (``HTML'').
Because the transmission providers do not provide the
organizational charts and/or job descriptions in standardized formats,
industry participants have difficulty viewing and downloading the
information. To rectify this problem, we encourage the industry to
reach consensus on an industry-wide uniform format, which could be
easily obtained and widely used by industry participants, to cover both
organizational charts and job descriptions, or at a minimum, one
uniform format for organizational charts and another uniform format for
job descriptions. To this end, we request that the How Group, within 90
days of the date of issuance of this order, develop an industry-wide
uniform format for organizational charts and job descriptions, and
submit its recommendations on this issue to the Commission.
III. Effective Date and Congressional Notification
Version 1.1 of the S&CP Document, as modified herein, will take
effect 60 days from the publication of this order in the Federal
Register. Version 1.2 of the S&CP Document, as modified herein, will
take effect on December 1, 1998. The revisions to Sec. 4.3.7.b of
Version 1.2 of the S&CP Document, pertaining to the masking of source
and sink information, will take effect on January 1, 1999.
The Commission has determined, with the concurrence of the
Administrator of the Office of Information and Regulatory Affairs of
the Office of Management and Budget, that this Rule is not a ``major
rule'' within the meaning of section 351 of the Small Business
Regulatory Enforcement Act of 1996.94 The Commission will
submit the rule to both houses of Congress and the Comptroller General
prior to its publication in the Federal Register.
---------------------------------------------------------------------------
\94\ 5 U.S.C. 804(2).
---------------------------------------------------------------------------
The Commission orders:
(A) The current S&CP Document (Version 1.1) is hereby modified, as
discussed in the body of this order, to incorporate the interim
procedures on price negotiation. This directive is to become effective
60 days from the date of publication of this order in the Federal
Register. The S&CP Document (Version 1.1), as modified herein, will be
superseded by the revised S&CP Document (Version 1.2), as shown on
Attachment 2 to this order, upon the effective date of the revised S&CP
Document (Version 1.2) ordered below in Ordering Paragraph (B).
(B) The revised S&CP Document (Version 1.2), as shown on Attachment
2 to this order, is hereby adopted for use by Transmission Providers,
to become effective on December 1, 1998, as discussed in the body of
this order.
(C) The revised S&CP Document (Version 1.2) is hereby modified, as
discussed in the body of this order, to revise references in
Sec. 4.3.7.b pertaining to the masking of source and sink information,
to become effective on January 1, 1999.
By the Commission. Commissioner Bailey dissented in part with a
separate statement attached. Commissioner Hebert concurred.
David P. Boergers,
Acting Secretary.
BILLING CODE 6717-01-P
Open Access Same-Time Information System and Standards of Conduct
[Docket No. RM95-9-003]
Issued June 18, 1998.
BAILEY, Commissioner, dissenting in part
I respectfully dissent from the decision to require the unmasking
of source and sink information and the posting of such information, for
public inspection, on a transmission provider's open access same-time
information system (OASIS).
In my judgment, this case presents a difficult balancing issue.
Specifically, it raises the issue of whether the public divulgence of
(what certain commenters characterize as) commercially and
competitively sensitive information is outweighed by the public's and
the Commission's need for such information for the purpose of detecting
possible undue discrimination or preference in the provision of
transmission service.
This issue--the balance between protecting commercially sensitive
business information and requiring its disclosure for the purpose of
monitoring and enforcement--is a recurring one. I have previously
discussed the issue in the context of separation of functions
requirements applicable to transmission providers \1\ and reporting and
filing requirements applicable to power suppliers with market-based
rate authority.\2\
\1\ See American Electric Power Service Corporation, et al., 81
FERC para. 61,332 (1997), order on reh'g, 82 FERC para. 61,131
(1998), reh'g pending.
\2\ See AES Huntington Beach, et al., L.L.C., 83 FERC para.
61,100 (1998).
I view this issue as particularly important as wholesale power
markets initiate and continue their development to competitive markets.
From a regulator's perspective, it presents a difficult quandary.
Should we require the divulgence of additional information to promote
our monitoring of the competitive market, when we suspect or are
informed that divulgence of such information would act to hinder
operation of the very competitive market we are attempting to foster?
Here, the information at issue is what the order characterizes as
``source and sink'' information. Source and sink information helps to
define the transmission service. Specifically, it identifies the
location of the generation resource and the location of the load to be
served.
This is very important information to the extent it allows the
transmission provider to assess the demands a request for transmission
service will place on its transmission system. I want to be clear that
I have absolutely no problem with the divulgence of source and sink
information, and any other related information, to the transmission
provider and any other entities, for the purpose of promoting the
reliability of the system and implementing appropriate line loading
relief procedures.
[[Page 38896]]
The question here, however, is very different--whether such
information should be made publicly available, by postings on the
OASIS, to the public and to the Commission.
Here, we see different viewpoints on the subject. We are informed
that transmission providers are, for the most part, indifferent on the
subject and simply want to be apprised of their OASIS posting
obligations in the aftermath of Order No. 889-A, which required the on-
line posting and negotiation of transmission discounts and the
unmasking of party names. (The OASIS ``How'' Working Group, a
representative industry coalition that periodically makes
recommendations as to proposed improvements in OASIS procedures and
protocols, takes no position on the subject and simply seeks Commission
``clarification'' as to whether the unmasking of names also requires
the unmasking of source and sink information.)
Transmission customers, on the other hand, offer strong opinion on
the subject. Power marketers and power producers articulate strong
opposition to the OASIS posting of source and sink information. They
believe that this information is commercially and competitively
sensitive, and that the public divulgence of the information will
stifle the development of competitive markets (particularly markets for
short-term energy transactions) and seriously impair their ability to
act as market intermediaries identifying and matching sellers and
purchasers.
Transmission customers without generation for sale offer a
different judgment. They believe that the disclosure of source and sink
information, identifying generation and load, will promote transparency
of utility operations and better enable customers and the Commission to
detect undue discrimination.
Today's order strikes a balance in favor of disclosure. It finds
that the information is necessary to better enable customers and the
Commission to detect and remedy undue discrimination and preference in
the provision of open access transmission service. It also finds that
disclosure is helpful in promoting the accuracy of the numbers--
available transmission capacity (ACT) and total transmission capacity
(TTC)--that transmission providers must post on the OASIS.
The order also helps to protect the commercial and competitive
sensitivity of source and sink information by delaying the posting of
such information until the time a transmission customer has confirmed
that it wishes to finalize the transaction. In this manner, other
transmission providers will not be able to swoop in and pirate off
pending transactions, through the use of source and sink information,
while they are still in the process of negotiation. In addition, the
order delays until January 1, 1999 the date by which transmission
providers must begin to post on the OASIS the source and sink
information provided by transmission customers.
I find this delay in the public posting of source and sink
information to be helpful in mitigating the commercial and competitive
consequences of disclosure. Nevertheless, even with the delay in
posting, I remain of the opinion that the balance tips in favor of
protecting commercially and competitively sensitive information against
public disclosure. I base this judgment on several considerations.
First, I remain unconvinced whether the unmasking of this
information is necessary or represents the best, or even an
appropriate, method of improving our ability to detect undue
discrimination or promote the validity of OASIS postings. The Electric
Power Supply Association, for example, in its comments refers to using
source and sink information for enforcement purposes as ``akin to going
after a bug with a cannon instead of a fly swatter.'' I wonder whether
there are more narrowly-tailored solutions, such as upgrading the data
retention or auditing procedures of Order No. 889.
Second, I am struck by the fact that a large segment of the
transmission customer community--power marketers and suppliers--which
has an obvious interest in promoting competitive markets and utility
compliance with our open access and OASIS initiatives actually opposes
this initiative. To the extent we act to improve our enforcement
mechanisms to the benefit of transmission customers, I would hope to
see greater unanimity of support among such purported beneficiaries. In
this regard, the commenters which oppose the unmasking of source and
sink information are among those attendees at our July, 1997 technical
conference on OASIS implementation which expressed great concern for
the validity and usefulness of OASIS postings and procedures and urged
a number of proposed improvements. However, unmasking of source and
sink information was not one of the improvements advanced for our
consideration.
Third, as today's order recognizes, the Commission itself recently
reaffirmed--as recently as March 1997 in Order No. 888-A--the
commercial and competitive sensitivity of source and sink information
by providing in the pro forma transmission tariff that such information
would remain confidential, except in certain limited circumstances.
What circumstances have transpired in the last year as to defeat the
presumption of confidentiality and to compel a reversal and the
disclosure of such information at this time?
Fourth, we have incomplete information upon which to take the
significant step of changing our mind and now unmasking information
concerning the location of generation and load. The Commission is
advancing an order on a variation of that which was set for notice and
comment last summer. We have not elicited comments on whether delaying
the posting of this information until the time of transaction
finalization, or delaying the effectiveness of revisions to the OASIS
Standards and Communications Protocols Document for seven months (until
January 1, 1999), is sufficient to mitigate the competitive concerns of
the commenters. The Coalition for a Competitive Market (CCEM) suggests,
as an alternative, that the Commission could balance its concerns by
further delaying disclosure of source and sink information for 30 days
after a request for service is accepted, denied or withdrawn.
I am basing my decision on the pleadings as compiled in this
proceeding. Upon the submission of further comment (such as in
petitions for rehearing) as to the balancing of interests between
protecting commercially and competitively sensitive information and
using such information to promote enforcement and monitoring of
markets, I could be persuaded to adopt a different balance.
At this time, however, I believe that the Commission's very
important interest in monitoring markets and protecting against the
abuse of monopoly power by transmission providers does not outweigh the
Commission's interest in protecting this type of commercially and
competitively sensitive information and, thereby, promoting a vigorous
and thriving wholesale power market.
For all of these reasons, I dissent from the decision to require
the unmasking of source and sink information and to adopt revised
procedures in the OASIS Standards and Communications Protocols Document
to reflect this unmasking of information. I concur in all other
respects with the findings of the order.
Vicky A. Bailey,
Commissioner.
Note: This attachment will not appear in the Code of Federal
Regulations.
[[Page 38897]]
Attachment 2--Standards and Communication Protocols for Open Access
Same-Time Information System (OASIS)
Version 1.2
May 27, 1998
Table of Contents
1. Introduction
1.1 Definition of terms
2. Network Architecture Requirements
2.1 Architecture of OASIS Nodes
2.2 Internet-Based OASIS Network
2.3 Communication Standards Required
2.4 Internet Tool Requirements
2.5 Navigation and Interconnectivity Between OASIS Nodes
3. Information Access Requirements
3.1 Registration and Login Requirements
3.2 Service Level Agreements
3.3 Access to Information
3.4 Provider Updating Requirements
3.5 Access to Changed Information
3.6 User Interaction With an OASIS Node
4. Interface Requirements
4.1 Information Model Concepts
4.2 OASIS Node Conventions and Structures
4.2.1 OASIS Node Naming Requirements
4.2.1.1. OASIS Node Names
4.2.1.2. OASIS Node and Primary Provider Home Directory
4.2.1.3 CGI Script Names
4.2.2 Data Element Dictionary
4.2.3 OASIS Template Constructs
4.2.3.1 Template Construction
4.2.3.2 Template Categories
4.2.3.3 Template HTML Screens
4.2.4 Query/Response Template Requirements
4.2.4.1 Query Requirements
4.2.4.2 Response Requirements
4.2.5 Input/Response Template Requirements
4.2.5.1 Input Requirements
4.2.5.2 Response to Input
4.2.6 Query Variables
4.2.6.1 General
4.2.6.2 Standard Header Query Variables
4.2.6.3 Responses to Queries
4.2.6.4 Multiple Instances
4.2.6.5 Logical Operations
4.2.6.6 Handling of Time Data Elements
4.2.6.7 Default Values
4.2.6.8 Limitations on Queries
4.2.7 CSV Format
4.2.7.1 General Record Format
4.2.7.2 Input Header Records
4.2.7.3 Response Header Records
4.2.7.4 Data Records
4.2.7.5 Continuation Records
4.2.7.6 Error Handling in CSV-Formatted Responses
4.2.8 Registration Information
4.2.8.1 General
4.2.8.2 Company Information
4.2.8.3 User Information
4.2.9 Representation of Time
4.2.9.1 General
4.2.9.2 Input Time
4.2.9.3 Output (Response) Time
4.2.10 Transaction Process
4.2.10.1 Purchase Transactions
4.2.10.2 Status Values
4.2.10.3 Dynamic Notification
4.2.10.3.1 HTTP Notification
4.2.10.3.2 E-mail Notification
4.2.11 Reference Identifiers
4.2.12 Linkage of Ancillary Services to Transmission Services
4.3 Template Descriptions
4.3.1 Template Summary
4.3.2 Query/Response of Posted Services Being Offered
4.3.2.1 Transmission Capacity Offerings Available for
Purchase (transoffering)
[[Page 38898]]
4.3.2.2 Ancillary Services Available for Purchase
(ancoffering)
4.3.3 Query/Response of Services Information
4.3.3.1 Transmission Services (transserv)
4.3.3.2 Ancillary Services (ancserv)
4.3.4 Query/Response of Schedules and Curtailments
4.3.4.1 Hourly Schedule (schedule)
4.3.4.2 Curtailment/Interruption (curtail)
4.3.5 Query/Response of Lists of Information
4.3.5.1 List (list)
4.3.6 Query/Response to Obtain the Audit log
4.3.6.1 Audit Log Information (auditlog)
4.3.7 Purchase Transmission Services
4.3.7.1 Customer Capacity Purchase Request (transrequest)
4.3.7.2 Status of Customer Purchase Request (transstatus)
4.3.7.3 Seller Approval of Purchase (transsell)
4.3.7.4 Customer Confirmation of Purchase (Input)
(transcust)
4.3.7.5 Alternate Point of Receipt/Delivery (transalt)
4.3.7.6 Seller to Reassign Service Rights to Another
Customer (transassign)
4.3.8 Seller Posting of Transmission Services
4.3.8.1 Seller Capacity Posting (transpost)
4.3.8.2 Seller Capacity Modify (transupdate)
4.3.9 Purchase of Ancillary Services
4.3.9.1 Customer Requests to Purchase Ancillary Services
(ancrequest)
4.3.9.2 Ancillary Services status (ancstatus)
4.3.9.3 Seller Approves Ancillary Service (ancsell)
4.3.9.4 Customer accepts Ancillary Service (anccust)
4.3.10 Seller Posting of Ancillary Services
4.3.10.1 Seller Ancillary Services Posting (ancpost)
4.3.10.2 Seller Modify Ancillary Services Posting
(ancupdate)
4.3.11 Informal Messages
4.3.11.1 Provider/Customer Want Ads and Informal Message
Posting Request (messagepost)
4.3.11.2 Message (message)
4.3.11.3 Provider/Sellers Message Delete Request
(messagedelete)
4.3.11.4 Personnel Transfers (personnel)
4.3.11.5 Discretion (discretion)
4.3.11.6 Standards of Conduct (stdconduct)
4.4 File Request and File Download Examples
4.4.1 File Example for Hourly Offering
4.4.2 File Example for Hourly Schedule Data
4.4.3 Customer Posting a Transmission Service Offering
4.4.4 Example of Re-aggregating Purchasing Services using
Reassignment
4.4.5 File Examples of the Use of Continuation Records
4.4.6 Example of Negotiation of Price
4.4.6.1 Negotiation with Preconfirmation
4.4.6.2 Negotiations without Preconfirmation
4.4.6.3 Multiple Step Negotiations
4.4.6.4 Negotiations Refused by Seller
4.4.6.5 Negotiations Withdrawn by Customer
4.5 Information Supported By Web Page
5. Performance Requirement
5.1 Security
5.2 Access Privileges
5.3 OASIS Response Time Requirements
5.4 OASIS Provider Account Availability
5.5 Backup and Recovery
5.6 Time Synchronization
5.7 TS Information Timing Requirements
5.8 TS Information Accuracy
5.9 Performance Auditing
5.10 Migration Requirements
Appendix A--Data Element Dictionary
Attachment 1.--Abbreviations of Names Used in Order
------------------------------------------------------------------------
Entity name Abbreviation
------------------------------------------------------------------------
Alabama Power Company............ (Alabama Power)
American Electric Power.......... (AEP)
American Public Power Association (APPA)
Central Illinois Lighting Company (CILCO)
Coalition for a Competitive (CCEM)
Electric Market.
Commercial Practices Working (Commercial Practices Group)
Group.
Commonwealth Edison Company...... (Commonwealth Edison)
Continental Power Exchange....... (CPEX)
Electric Clearinghouse, Inc...... (Electric Clearinghouse)
[[Page 38899]]
Electric Power Research Institute (EPRI)
Electric Power Suppliers (EPSA)
Association.
Florida Power Corporation........ (Florida Power Corp)
Georgia Power Company............ (Georgia Power)
Gulf Power Company............... (Gulf Power)
Mississippi Power Company........ (Mississippi Power)
OASIS How Working Group (EPRI)... (How Group)
National Rural Electric (NRECA)
Cooperative Association.
New York Power Pool.............. (NYPP)
New York State Electric & Gas (NYSEG)
Corp.
North American Electric (NERC)
Reliability Council.
Pennsylvania--New Jersey-- (PJM)
Maryland Power Pool.
PECO Energy Company--Power Team.. (PECO)
PECO Energy Company--Power Team (PECO Energy)
and Vitol Gas & Electric, Ltd.
Savannah Electric and Power (Savannah)
Company.
Southern Company Services, Inc... (Southern)
------------------------------------------------------------------------
1. Introduction
1.1 Definition of Terms
The following definitions are offered to clarify discussions of the
OASIS in this document.
a. Transmission Services Information (TS Information) is
transmission and ancillary services information that must be made
available by public utilities on a non-discriminatory basis to meet the
regulatory requirements of transmission open access.
b. Open Access Same-Time Information System (OASIS) comprises the
computer systems and associated communications facilities that public
utilities are required to provide for the purpose of making available
to all transmission users comparable interactions with TS Information.
c. Open Access Same-Time Information System Node (OASIS Node) is a
subsystem of the OASIS. It is one computer system in the (OASIS) that
provides access to TS Information to a Transmission Customer.
d. Transmission Provider (TP or Primary Provider) is the public
utility (or its designated agent) that owns, operates or controls
facilities used for the transmission of electric energy in interstate
commerce. (This is the same term as is used in Part 35.3).
e. Transmission Customer (TC or Customer) is any eligible Customer
(or its designated agent) that can or does execute a transmission
service agreement or can or does receive transmission service. (This is
the same term as is used in Part 35.3).
f. Secondary Transmission Provider (ST, Reseller, or Secondary
Provider) is any Customer who offers to sell transmission capacity it
has purchased. (This is the same as Reseller in Part 37).
g. Transmission Services Information Provider (TSIP) is a
Transmission Provider or an agent to whom the Transmission Provider has
delegated the responsibility of meeting any of the requirements of Part
37. (This is the same as Responsible Party in Part 37).
h. Value-Added Transmission Services Information Provider (VTSIP)
is an entity who uses TS Information in the same manner as a Customer
and provides value-added information services to its Customers.
2. Network Architecture Requirements
2.1 Architecture of OASIS Nodes
a. Permit Use of Any OASIS Node Computers: TSIPs shall be permitted
to use any computer systems as an OASIS Node, so long as they meet the
OASIS requirements.
b. Permit Use of Any Customer Computers: OASIS Nodes shall permit
the use by Customers of any commonly available computer systems, as
long as they support the required communication links to the Internet.
c. Permit the Offering of Value-Added Services: TSIPs are required,
upon request, to provide their Customers the use of private network
connections on a cost recovery basis. Additional services which are
beyond the scope of the minimum OASIS requirements are also permitted.
When provided, these private connections and additional services shall
be offered on a fair and non-discriminatory basis to all Customers who
might choose to use these services.
d. Permit Use of Existing Communications Facilities: In
implementing the OASIS, the use of existing communications facilities
shall be permitted. The use of OASIS communication facilities for the
exchange of information beyond that required for open transmission
access (e.g., transfer of system security or operations data between
regional control centers) shall also be permitted, provided that such
use does not negatively impact the exchange of open transmission access
data and is consistent with the Standards of Conduct in Part 37.
e. Single or Multiple Providers per Node: An OASIS Node may support
a single individual Primary Provider (plus any Secondary Providers) or
may support many Primary Providers.
2.2 Internet-Based OASIS Network
a. Internet Compatibility: All OASIS Nodes shall support the use of
internet tools, internet directory services, and internet communication
protocols necessary to support the Information Access requirements
stated in Section 4.
b. Connection through the Public Internet: Connection of OASIS
Nodes to the public Internet is required so that Users may access them
through Internet links. This connection shall be made through a
firewall to improve security.
[[Page 38900]]
c. Connection to a Private Internet Networks: OASIS Nodes shall
support private connections to any OASIS User (User) who requests such
a connection. The TSIP is permitted to charge the User, based on cost,
for these connections. The same internet tools shall be required for
these private networks as are required for the public Internet. Private
connections must be provided to all users on a fair and
nondiscriminatory basis.
d. Internet Communications Channel: The OASIS Nodes shall utilize a
communications channel to the Internet which is adequate to support the
performance requirements given the number of Users subscribed to the
Providers on the Node (see section 5.3).
2.3 Communications Standards Required
a. Point-to-Point Protocol (PPP) and Internet Protocol Control
Protocol (IPCP) (reference RFCs 1331 and 1332) shall be supported for
private internet network dial-up connections.
b. Serial Line Internet Protocol (SLIP) (reference RFC 1055) shall
be supported for private internet network dial-up connections.
c. Transport Control Protocol and Internet Protocol (TCP/IP) shall
be the only protocol set used between OASIS Nodes whenever they are
directly interconnected, or between OASIS Nodes and Users using private
leased line internet network connections.
d. Hyper Text Transport Protocol (HTTP), Version 1.0 (RFC 1945),
shall be supported by User's web browsers so they can use it to select
information for viewing displays and for downloading and uploading
files electronically.
e. Internet Protocol Address: All OASIS Nodes are required to use
an IP address registered with the Internet Network Information Center
(InterNIC), even if private connections are used.
2.4 Internet Tool Requirements
Support the following specific internet tools is required, both for
use over the public Internet as well as for any private connections
between Users and OASIS Nodes:
a. Hypertext Markup Language (HTML), at least Version 3.2 shall be
used by supported by User's browsers as a standards tool for viewing
information.
b. HTML Forms shall be provided by the TSIPs to allow Customers to
enter information to the OASIS Node.
c. Domain Name Service (DNS) (ref. RFC 1034, 1035) shall be
provided as a minimum by the TSIPs (or their Internet Service Provider)
for the resolution of IP addresses to allow Users to navigate easily
between OASIS Nodes.
d. Simple Network Management Protocol (SNMP) is recommended but not
required to provide tools for operating and managing the network, if
private interconnections between OASIS Nodes are established.
e. The Primary Provider shall support E-mail for exchanges with
Customers, including the sending of attachments. The protocols
supported shall include, as a minimum, the Simple Messaging Transfer
Protocol (SMTP), Post Office Protocol (POP(), and Multipurpose Internet
Mail Extensions (MIME).
2.5 Navigation and Interconnectivity Between Oasis Nodes
a. World Wide Web Browsers: TSIPs shall permit Users to navigate
using WWW browsers for accessing different sets of TS Information from
one Provider, or for getting to TS Information from different Providers
on the same OASIS Node. These navigation methods shall not favor User
access to any Provider over another Provider, including Secondary
Providers.
b. Internet Interconnection across OASIS Nodes: Navigation tools
shall not only support navigation within the TSIP's Node, but also
across interconnected OASIS Nodes. This navigation capability across
interconnected Nodes shall, as a minimum, be possible through the
public Internet.
3. Information Access Requirements
3.1 Registration and Login Requirements
a. Location of Providers: To provide Users with the information
necessary to access the desired Provider, all Primary Providers shall
register their OASIS Node URL address with www.tsin.com. This URL
address should include the unique four letter acronym the Primary
Provider will use as the PRIMARY__PROVIDER__CODE.
b. Initial User Registration: TSIPs shall require Users to register
with a Primary Provider before they are permitted to access the
Provider's TS Information. There must be a reference pointing to
registration procedures on each Primary Provider's home page.
Registration procedures may vary with the administrative requirements
of each Primary Provider.
c. Initial Access Privileges: Initial registration shall permit a
User only the minimum Access Privileges. A User and a Primary Provider
shall mutually determine what access privilege the User is permitted.
The TSIP shall set a User's Access Privilege as authorized by the
Primary Provider.
d. User Login: After registration, Users shall be required to login
every time they establish a dial-up connection. If a direct, permanent
connection has been established, Users shall be required to login
initially or any time the connection is lost. Use of alternative forms
of login and authentication using certificates and public key standards
is acceptable.
e. User Logout: Users shall be automatically loged out any time
they are disconnected. Users may logout voluntarily.
3.2 Service Level Agreements
Service Level Agreements: It is recognized that Users will have
different requirements for frequency of access, performance, et., based
on their unique business needs. To accommodate these differing
requirements, TSIPs shall be required to establish a ``Service Level
Agreement'' with each User which specifies the terms and conditions for
access to the information posted by the Providers. The default Service
Level Agreement shall be Internet access with the OASIS Node meeting
all minimum performance requirements.
3.3 Access to Information
a. Display: TSIPs shall format all TS Information on HTML format
such that it may be viewed and read directly by Users without requiring
them to download it. This information shall be in clear English as much
as possible,
[[Page 38901]]
with the definitions of any mnemonics or abbreviations available on-
line. The minimum information that is to be displayed is provided in
the Templates in Section 4.3.
b. Read-Only Access to TS Information: For security reasons, Users
shall have read-only access to the TS Information. They shall not be
permitted to enter any information except where explicitly allowed,
such as HTML transaction request forms or by the Templates in Section
4.3.
Downloading Capability: Users shall be able to download from an
OASIS Node the TS Information in electronic format as a file. The rules
for formatting of this data are described in Section 4.2.
d. On-Line Data Entry on Forms: Customers shall be permitted to
fill out on-line the HTML forms supplied by the TSIPs, for requesting
the purchase of services and for posting of products for sale (by
Customers who are resellers). Customers shall also be permitted to
fill-out and post Want-Ads.
e. Uploading Capability: Customers shall be able to upload to OASIS
Nodes the filled-out forms. TSIPs shall ensure that these uploaded
forms are handled identically to forms filled out on-line. TSIPs shall
provide forms that support the HTTP input of Comma Separated Variable
(CSV) records. This capability shall permit a Customer to upload CSV
records using standard Web browsers or additional client software (such
as fetch__http) to specify the location of the CSV records stored on
the Customer's hard disk.
f. Selection of TS Information: Users shall be able to dynamically
select the TS Information they want to view and/or download. This
selection shall be, as a minimum, through navigation to text displays,
the use of pull-down menus to select information for display, data
entry into forms for initiating queries, and the selection of files to
download via menus.
3.4 Provider Updating Requirements
The following are the Provider update requirements:
a. Provider Posting of TS Information: Each Provider (including
Secondary Providers and Value-Added Providers) shall be responsible for
writing (posting) and updating TS Information on their OASIS node. No
User shall be permitted to modify a Provider's Information.
b. Info.htm: Each Provider shall provide general information on how
to use their node and describe all special aspects, such as line
losses, congestion charges and assistance. The address for the
directory of this information shall be info.htm, an HTML web page,
linked to the Provider's registered URL address.
c. OASIS Node Space for Secondary Provider: To permit Users to
readily find TS Information for the transmission systems that they are
interested in. TSIPs shall provide database space on their OASIS Node
for all Secondary Providers who have purchased, and who request to
resell, transmission access rights for the power systems of the Primary
Providers supported by that Node.
d. Secondary Provider Posting to Primary Provider Node: The
Secondary Providers shall post the relevant TS Information on the OASIS
Node associated with each Primary Provider from whom the transmission
access rights were originally purchased.
e. Secondary Provider Posting Capabilities: The TSIPs shall ensure
that the Secondary Providers shall be able to post their TS Information
to the appropriate OASIS Nodes using the same tools and capabilities as
the Customers, meet the same performance criteria as the Primary
Providers, and allow users to view these postings on the same display
page, using the same tables, as similar capacity being sold by the
Primary Providers.
f. Free-Form Posting of non-TS Information. The TSIP shall ensure
that non-TS Information such as Want-Ads, may be posted by Providers
and Customers, and that this information is easily accessible by all
Users. The TSIP shall be allowed to limit the volume and/or to charge
for the posting of non-TS Information.
g. Time Stamps: All TS Information shall be associated with a time
stamp to show when it was posted to the OASIS Node.
h. Transaction Tracking by an Assignment Reference Number: All
requests for purchase of transmission or ancillary services will be
marked by a unique accounting number, called an assignment reference.
i. Time-Stamped OASIS Audit Log: All posting of TS Information, all
updating of TS Information, all User logins and disconnects, all User
download requests, all Service Requests, and all other transactions
shall be time stamped and stored in an OASIS Audit Log. This OASIS
Audit Log shall be the official record of interactions, and shall be
maintained on-line for download for at least 90 days. Changes in the
values of posted Capacity (Available Transfer Capability) must be
stored in the on-line audit Log for 20 days. Audit records must be
maintained for 3 years off-line and available in electronic form within
seven days of a Customer request.
j. Studies: A summary description with dates, and programs used of
all transmission studies used to prepare data for the Primary
Provider's ATC and TTC calculation will be provided along with
information as to how to obtain the study data and results.
3.5 Access to Changed Information
a. General Message & Log: TSIPs shall post a general message and
log that may be read by Users. The message shall state that the
Provider has updated some information, and shall contain (or point to)
a reverse chronological log of those changes. This log may be the same
as the Audit Log. The User may use the manual capability to see the
message.
b. TSIP Notification Design Responsibilities: The TSIP shall avoid
a design that could cause serious performance problems by necessitating
frequent requests for information from many Users.
3.6 User Interaction With an OASIS Node
There are three basic types of User interactions which must be
supported by the OASIS Node. These interactions are defined in Section
4.3.
a. Query/Response: The simplest level of interactions is the query
of posted information and the corresponding response. The User may
determine the scope of the information queried by specifying values,
through an HTML form,
[[Page 38902]]
a URL string, or an uploaded file, using Query Variables and their
associated input values as defined with each Template in Section 4.3.
The response will be either an HTML display or a record oriented file,
depending on the output format that the User requests.
The TSIP may establish procedures to restrict the size of the
response, if an overly broad query could result in a response which
degrades the overall performance of the OASIS Node for their Users.
b. Purchase Request: The second type of Customer interaction is the
submittal of a request to purchase a service. The Customer completes an
input form, a URL string or uploads a file and submits it to the OASIS
Node. The uploaded file can either be a series of query variables or a
record oriented file.
The request is processed by the Seller of the service, possibly
off-line from the OASIS Node, and the status is updated accordingly.
If a purchase request is approved by the Seller, then it must be
again confirmed by the Customer. Once the Customer confirms an approved
purchase, a reservation for those services is considered to exist,
unless later the reservation is reassigned, displaced, or annulled.
c. Upload and Modify Postings: Customers who wish to resell their
rights may upload a form, create the appropriate URL or upload a file
to post services for sale. A similar process applies to eligible Third
Party Sellers of ancillary services. The products are posted by the
TSIP. The seller may monitor the status of the services by requesting
status information. Similarly the Seller may modify its posted
transmission services by submitting a service modification request
through a form, a URL query, or by uploading a file.
4. Interface Requirements
4.1 Information Model Concepts
a. ASCII-Bases OASIS Templates: For providing information to Users,
TSIPs shall use the specified OASIS Templates. These Templates define
the information which must be presented to Users, both in the form of
graphical displays and as downloaded files. Users shall be able to
request Template information using query-response data flows. The OASIS
Templates are described in section 4.3. The Data Element Dictionary,
which defines the data elements in the OASIS Templates, is provided in
Appendix A.
Data elements must be used in the exact sequence and number as
shown in the Templates when file uploads and downloads are used.
Although the contents of the graphical displays are precisely defined
as the same information as in the Templates, the actual graphical
display formats of the TS information are beyond the scope of the OASIS
requirements. Due to the nature of graphical displays, there may be
more than one graphical display used to convey the information in a
single Template.
b. ASCII-Based OASIS File Structures: For uploading requests from
and downloading information to Users, TSIPs shall use specific file
structures that are defined for OASIS Template information (see section
4.2). These file structures are based on the use of headers which
contain the Query Variable information, including the name of the OASIS
Template. These headers thus determine the contents and the format of
the data follows. Although headers may not be essential if file
transfers contain the exact sequence and number of data elements as the
Templates, this feature is being preserved for possible future use when
additional flexibility may be allowed.
4.2 OASIS Node Conventions and Structures
4.2.1 OASIS Node Naming Requirements
The following naming conventions shall be used to locate
information posted on OASIS. OASIS naming conventions shall conform to
standard URL structures.
4.2.1.1 OASIS Node Names
In order to provide a consistent method for locating an OASIS Node,
the standard Internet naming convention shall be used. All OASIS Node
names shall be unique. Each Primary Provider OASIS Node name and home
directory shall be registered with the master OASIS directory site at
http://www.tsin.com. OASIS Node names shall be stored in an Internet
DNS name directory.
4.2.1.2 OASIS Node and Primary Provider Home Directory
The home directory name on an OASIS Node shall be ``OASIS'' to
identify that the directory is related to the OASIS. The directory of
each Primary Provider shall be listed under the ``OASIS'' directory:
http://(OASIS Node name)/OASIS/(PRIMARY__PROVIDER__CODE)
Where:
(OASIS Node name) is the World Wide Web URL address of the OASIS
Information Provider.
(PRIMARY__PROVIDER__CODE is the 4 character acronym of the primary
provider.
(PRIMARY__PROVIDER__CODEs shall be registered with the master OASIS
directory site at http://www.tsin.com. A pointer to user registration
information shall be located on the Primary Provider's home page.
4.2.1.3 CGI Script Names
Common Gateway Interface (CGI) scripts shall be located in the
directory ``data'' as follows:
http://(OASIS Node name)/OASIS/(PRIMARY__PROVIDER__CODE)/data/(cgi
script name)?(query variables)
Where:
(cgi script name) is the OASIS Template name (see Section 4.3).
Other cgi scripts may be defined as required to implement the HTML
interface to the documented templates. (query variables) is a list of
query variables with their settings formatted as defined by the HTTP
protocol (i.e., URL encoded separated by ampersands).
[[Page 38903]]
Example:
To request the hourly schedule Template at Primary Provider WXYZ Co.
http://www.wxyz.com/oasis/wxyz/data/schedule?templ=schedule& ver=1.2&
fmt=data & stime=19960412040000PD &sptime=19960412100000PD& pprov=wxyz
4.2.2 Data Element Dictionary
The following are the requirements for the Data Element Dictionary:
a. Definition of OASIS Information Elements: All OASIS Information
data elements shall be defined in the Data Element Dictionary which
will be stored in the OASIS Node directory:
http://(OASISNode Name)/OASIS/(PRIMARY__PROVIDER__CODE/ (datadic.html 1
datadict.txt)
Where:
datadic.html is the HTML version of the data element dictionary
datadic.txt is the ASCII text version of the data element dictionary
The Data Element Dictionary is defined in Appendix A.
b. Provider-specific Data Element Values: The valid values that
certain OASIS Information data elements may take on, such as
PATH__NAME, etc., are unique to a Primary Provider. Names which must be
uniquely identified by Primary Provider shall be listed on-line on the
OASIS Node via the LIST Template (see Section 4.3.5). In posting OASIS
information associated with data elements which are not free-form text,
TSIPs shall use only the accepted data element values listed in the
Data Element Dictionary and/or those values posted in the LIST of
provider specific names provided on the OASIS.
4.2.3 OASIS Template Constructs
4.2.3.1 Template Construction
Section 4.3 lists the set of OASIS Templates that shall be
supported by all OASIS nodes. These OASIS Templates are intended to be
used precisely as shown for the transfer of data to/from OASIS, and
identify, by Data Elements names, the information to be transferred.
The construction of the OASIS Templates shall follow the rules
described below:
a. Unique OASIS Template Name: Each type of OASIS Template shall be
identified with a unique name which shall be displayed to the User
whenever the OASIS Template is accessed.
b. Transfer Protocol: OASIS Templates are transferred using the
HTTP protocol. Templates shall support both the ``GET'' and ``POST''
methods for transferring ``query string'' name/value pairs, as well as
the OASIS specific ``comma separated value'' (CSV) format for posting
and retrieval of information from OASIS. HTML screens and forms shall
be implemented for each OASIS Template.
c. Source Information: Each OASIS Template shall identify the
source of its information by including or linking to the name of the
Primary Provider, the Secondary Provider, or the Customer who provided
the information.
d. Time Of Last Update: Each OASIS Template shall include a time
indicating when it was created or whenever the value of any Data
Element was changed.
e. Data Elements: OASIS Templates shall define the elementary Data
Element Dictionary names for the data values to be transferred or
displayed for that Template.
f. Documentation: OASIS Information shall be in non-cryptic
English, with all mnemonics defined in the Data Element Dictionary or a
glossary of terms. TSIPs shall provide on-line descriptions and help
screens to assist Users understanding the displayed information.
Documentation of all formats, contents, and mnemonics shall be
available both as displays and as files which can be downloaded
electronically. In order to meet the ``User-Friendly'' goal and permit
the flexibility of the OASIS to expand to meet new requirements, the
OASIS Templates shall be as self-descriptive as possible.
4.2.3.2 Template Categories
OASIS Templates are grouped into the following two major
categories:
a. Query/Response: These Templates are used to query and display
information posted on OASIS. Each query/response Template accepts a set
of user specified Query Variables and returns the appropriate
information from data posted on OASIS based on those query variables.
The valid Query Variables and information to be returned in response
are identified by Data Element in Section 4.3.
b. Input/Response: These Templates are used to upload/input
information on OASIS. The required input information and information to
be returned in response are identified by Data Element in Section 4.3,
Template Descriptions.
4.2.3.3 Template HTML Screens
Though the exact form and content of the HTML screens and forms
associated with the OASIS Templates are not dictated by this document,
the following guidelines shall be adhered to for all HTML screens and
forms implemented on OASIS:
a. Data Element Headings: Data displayed in an HTML screen/form
shall be labeled such that the associated data value(s) is(are) easily
and readily identifiable as being associated with a particular OASIS
Template Date Element. HTML ``Hot-Links'' or other pointer mechanisms
may be provided for Data Element headings in OASIS Templates which
permit the User to access documentation describing the meaning, type,
and format of the associated data.
b. Display Limitations: HTML screens and forms shall be implemented
in such a way to allow the display of all data specified for each OASIS
Template. This may take the form of ``wrapping'' of lines of
information on the screen, the use of horizontal and/or vertical
scrolling, or the use of ``Hot-Links'' or other pointer mechanisms.
There is not necessarily a one-to-one relationship between OASIS
implemented HTML screens and their associated Template. However, all
Template data elements shall be viewable through one or more HTML
screens.
c. Template Navigation: HTML ``Hot-Links'' or other pointer
mechanisms may be provided to assist the navigation between screens/
forms associated with related OASIS Templates.
[[Page 38904]]
4.2.4 Query/Response Template Requirements
Retrieval of information posted on OASIS is supported by the Query/
Response Templates. The ``query'' identifies the OASIS Template and
optionally supplies additional Data Elements which may be used to
select specific information to be returned in the ``response''.
4.2.4.1 Query Requirements
Query information is transferred to OASIS using the HTML protocol
as a string of Query Variables in the form of name/value pairs. Query
Variable name/value pairs are specified as a collection encoded strings
(e.g., blank characters replaced by plus (+) character, etc.) in the
form of name=value, with each name/value pair separated by ampersands
(&) (see section 4.2.6). OASIS shall support the following methods for
Users to input Query information:
a. HTML: HTML FORM input and/or hypertext links shall be provided
to allow Users to specify OASIS Template Query Variables. This will be
the easiest way to obtain information should be the choice of most
causal Users and for simple requests. The exact nature and form of
these HTML screens are not specified, and may differ between OASIS
nodes.
b. GET Method: The HTML GET method for specifying query information
appended to a standard OASIS URL shall be supported. Using this method,
the name=value formatted Query Variables preceded by a question mark
(?) are appended to the URL. Each ``name'' in a name/value pair
corresponds to a Data Element name associated with that Template, OASIS
shall support the specification of all Data Elements associated with a
Template by both their full name and alias as defined in the Data
Dictionary. The ``value'' in a name/value pair represents the value to
be associated with the Data Element being specified in the appropriate
format as defined in the Data Dictionary and encoded according to the
HTML protocol.
c. POST Method: The HTML POST method for specifying query
information in the message body shall be supported. Using this method,
the name=value formatted Query Variables shall be transferred to OASIS
suing the ``Content-length:'' HTML header to define the length in bytes
of the encoded query string and the ``Content-type: application/x-www-
form-urlencoded'' HTML header to identify the data type included in the
message body. Each ``name'' in a name/value pair corresponds to a Data
Element name associated with that Template. OASIS shall support the
specification of all Data Elements associated with a Template by both
their full name and alias as defined in the Data Dictionary. The
``value'' in a name/value pair represents the value to be associated
with the Data Element being specified in the appropriate format as
defined in the Data Dictionary and encoded according to the HTML
protocol.
User queries using any of the above methods are supported directly
by the User's web browser software. More sophisticated data transfer
mechanisms, such as the automated querying of information based on
Query Variable strings contained in a User data file (i.e., ``uploading
a file containing a URL string), require appropriate software (e.g.,
``fetch__http'') running on the User's computer system to effect the
data transfer.
4.2.4.2 Response Requirements
In response to a validly formatted Query for each Query/Response
OASIS Template, the OASIS shall return the requested information in one
of two forms based on the User specified OUTPUT__FORMAT Query Variable:
a. HTML: If the User requests the response to have the format of
``HTML'' (OUTPUT__FORMAT=HTML) then the response from the OASIS shall
be a web page using the HTML format. This shall be the default for all
Query/Response Templates.
b. CSV Format: Comma Separated Value (CSV) format
(OUTPUT__FORMAT=DATA) returns the requested information in the body of
the HTML response message. The ``Content-length:'' HTML header shall
define the length in bytes of the response, and the ``Content-type:
text/x-oasis-csv'' HTML header shall be used to identify the data type
included in the message body (see CSV File Format).
4.2.5 Input/Response Template Requirements
The posting of information on OASIS, including reservations for
transmission/ancillary service, services for sale on the secondary
market, etc., is supported by the Input/Response Templates. The
``input'' identifies the required data associated with an OASIS
Template to be posted on OASIS, and the ``response'' specifies the
information returned to the User.
4.2.5.1 Input Requirements
Input information is transferred to OASIS using the HTTP protocol
as either a string of Query Variable in the form of name/value pairs,
or as a Comma Separated Value (CSV) message. Query Variable name/value
pairs are specified as a collection of encoded strings (e.g., blank
characters replaced by plus (+) character, etc.) in the form of
name=value, with each name/value pair separated by ampersands (&). CSV
formatted messages are specified in the body of an HTTP message as a
series of data records preceded by a fixed set of header records (see
section 4.2.7).
OASIS shall support the following methods for Users to transfer
Input data:
a. HTML: HTML FORM input shall be provided to allow Users to
specify the necessary Input data associated with each Input/Response
OASIS Template. This may be in the form of fill in blanks, buttons,
pull-down selections, etc., and may use either the GET or POST methods.
The exact nature and form of these HTML screens are not specified, and
may differ between OASIS nodes.
b. GET Method: The HTTP GET method for specifying Input information
in the form of a query string appended to a standard OASIS URL shall be
supported. Using this method, the name=value formatted Query Variables
preceded by a question mark (?) are appended to the URL. Each ``name''
in a name/value pair corresponds to a Data Element name associated with
that Template. OASIS shall support the specification of all Data
Elements associated with a Template by both their full name and alias
as defined in the Data Dictionary. The ``value'' in a name/value pair
represents the value to be associated with the Data Element being
specified in the appropriate format as defined in the Data Dictionary
and encoded according to the HTTP protocol.
[[Page 38905]]
c. POST Method: The HTTP POST method for specifying Input
information in the form of a query string in the message body shall be
supported. Using this method, the name-value formatted Query Variables
shall be transferred to OASIS using the ``Content-length:'' HTTP header
to define the length in bytes of the encoded query string and the
``Content-type: application/x-www-form-urlencoded'' HTTP header to
identify the data type included in the message body. Each ``name'' in a
name/value pair corresponds to a Data Element name associated with that
Template. OASIS shall support the specification of all Data Elements
associated with a Template by both their full name and alias as defined
in the Data Dictionary. The ``value'' in a name/value pair represents
the value to be associated with the Data Element being specified in the
appropriate format as defined in the Data Dictionary and encoded
according to the HTTP protocol.
d. CSV Format: Comma Separated Value (CSV) formatted Input
information transferred in the body of a User's HTTP message shall be
supported. The ``Content-length:'' HTTP header shall define the length
in bytes of the Input, and the ``Content-type: text/x-oasis-csv'' HTTP
header shall be used to identify the data type included in the message
body.
4.2.5.2 Response to Input
In response to a validly formatted Input for each Input/Response
OASIS Template, the OASIS shall return an indication as to the success/
failure of the requested action. The OASIS shall respond to the Input
in one of two forms, based on the OUTPUT__FORMAT, which was input by a
User either as a Query Variable or in a CSV format Header Record:.
a. HTML: If the User requests the response to have the format of
``HTML'' (OUTPUT__FORMAT=HTML) then the response from the OASIS shall
be a web page using the HTML format. This shall be the default for all
Input/Response Templates invoked using either the FORM, GET or POST
methods of input.
b. CSV Format: Coma Separated Value (CSV) format
(OUTPUT__FORMAT=DATA) returns the response information in the body of
the HTTP response message. The ``Content-length:'' HTTP header shall
define the length in bytes of the response, and the ``Content-type:
text/x-oasis-csv'' HTTP header shall be used to identify the data type
included in the message body. This shall be the default for all Input/
Response Templates invoked using the CSV Format methods of input.
4.2.6 Query Variables
4.2.6.1 General
Both Query/Response and Input/Response OASIS Templates shall
support the specification of a query string consisting of Query
Variables formatted as name/value pairs. OASIS shall support the
specification of Data Element names (``name'' portion of name=value
pair) in both the full name and alias forms defined in the Data
Dictionary. OASIS shall support the specification of Query Variables
from the User using either the HTTP GET or POST methods. On input, Data
Element names and associated values shall be accepted and processed
without regard to case. On output, Data Element names and associated
values may not necessarily retain the input case, and could be returned
in either upper or lower case.
4.2.6.2 Standard Header Query Variables
The following standard Query Variable Data Elements shall be
supported for all OASIS Templates and must be entered for each Query by
a User:
.VERSION
TEMPLATE
OUTPUT__FORMAT
PRIMARY__PROVIDER__CODE
PRIMARY__PROVIDER__DUNS
RETURN__TZ
Since these header Query Variables must be supported for all
Templates, they are not listed explicitly in the Template description
in Section 4.3.
All standard header Query Variables with appropriate values must be
entered by the User.
4.2.6.3 Responses to Queries
Responses to Queries will include the following information as a
minimum:
TIME__STAMP
VERSION
TEMPLATE
OUTPUT__FORMAT
PRIMARY__PROVIDER__CODE
PRIMARY__PROVIDER__DUNS
RETURN__TZ
The additional information shall include:
a. The requested information as defined by the Template indicated
in the Query.
b. For CSV downloads, the additional header Data Elements required
(see section 4.2.7.3).
4.2.6.4 Multiple Instances
Certain Query Variables may be repeated in a given Query/Response
OASIS Template query string. Where such multiple instances are
documented in the Template definitions using an asterix (*) after the
query variable. When more than one instance of the query Variable is
specified in the query string, OASIS shall recognize such multiple
instances by either the Data Element's full name or alias suffixed with
sequential numeric qualifiers starting with
[[Page 38906]]
the number 1, (e.g., PATH__NAME1=abc&PATH__NAME2=xyz, or
PATH1=abc&PATH2=xyz). At least 4 multiple instances will be permitted
for each query variable marked with an asterix (*).
4.2.6.5 Logical Operations
OASIS shall use the following logical operations when processing
Query Variables for Query/Response OASIS Templates. All Query
Variables, with the exception of multiple instances of the same Query
Variable Data Element, shall be operated on to return information based
on the logical-AND of those Query Variables. For example, the query
string ``...SELLER__CODE=abc&PATH=xyz...'' should return information
associated with only those records that are on transmission path
``xyz'' AND associated with transmission provider ``abc.'' Multiple
instances of the same Query Variable shall be operated on as logical-
OR. For example,''... SELLER__CODE=abc&PATH1=xyz&PATH2=opq...'' should
return information associated with transmission provider ``abc'' AND
either transmission path ``xyz'' OR transmission path ``opq''. Some
logical operations may exclude all possibilities, such that the
responses may not contain any data.
4.2.6.6 Handling of Time Data Elements
In cases where a single query variable is provided to select
information associated with a single template data element that
represents a point in time (e.g., TIME__OF__LAST__UPDATE), OASIS shall
return to the User all requested information whose associated data
element time value (e.g. TIME__OF__LAST__UPDATE) is equal to or later
than the value specified by the query variable. In this case the stop
time is implicitly ``now''.
A pair of query variables (e.g. START__TIME__QUEUED and
STOP__TIME__QUEUED) that represents the start and stop of a time
interval but is associated with one single template data element (e.g.
TIME__QUEUED shall be handled by OASIS to return to the User all
requested information whose associated data element time value falls
within the specified time interval.
A pair of query variables (e.g. START__TIME and STOP__TIME query
variables) that represents the start and stop of one time interval but
is associated with another pair of template data elements (e.g.
START__TIME and STOP__TIME of a service offering) that represents a
second time interval, shall be handled by OASIS to return to the User
all requested information whose associated data element time interval
overlaps any portion of the specified time interval. Specifically, the
START__TIME query variable selects all information whose STOP__TIME
data element value is later than the START__TIME query variable, and
the STOP__TIME query variable selects all information whose START__TIME
data element value is earlier than the STOP__TIME query variable. For
example:
The transoffering template query string ``START__TIME
970101000000ES&STOP__TIME970201000000ES'' shall select from the OASIS
database all associated offerings whose start/stop times overlap any
portion of the time from 00:00 January 1, 1997, to 00:00 February 1,
1997. This would include offerings that (1) started prior to Jan. 1 and
stopped any time on or after Jan. 1, and (20 started on or after Jan. 1
but before Feb. 1
For changes to and from daylight savings time, either Universal
Time or the correct time and zone must be used, based on whether
daylight savings time is in effect.
All Time values shall be checked upon input to ensure their
validity with respect to date, time, time zone, and daylight savings
time.
4.2.6.6 Default Values
Query Variables that are not specified by the User may take on
default values as appropriate for that Query Variable at the discretion
of the OASIS TSIP.
4.2.6.8 Limitations on queries
OASIS TSIP may establish validation procedures and/or default
values for Query Variables to restrict the size and/or performance
impact of overly broad queries.
4.2.7 CSV Format
4.2.7.1 General Record Format
OASIS Users shall be able to upload information associated with
Input/Response OASIS Templates and download information associated with
all OASIS Templates using a standardized Comma Separated Value (CSV)
format. CSV formatted data is transferred to/from OASIS as part of the
body of an HTTP message using the ``Content-length:'' HTTP header to
define the length in bytes of the message body, and the ``Content-type:
text/x-oasis-csv'' HTTP header to identify the data type associated
with the message body. CSV formatted data consists of a fixed set of
header records followed by a variable number of data records. Each
record shall be separated by a carriage return plus line feed (denoted
by the symbol in all examples). The fields within a record
shall be delimited by commas(,). All data within a CSV formatted
message shall use printable ASCII characters with no other special
embedded codes, with the exception of the special encoding requirements
associated with text fields.
4.2.7.2 Input Header Records
The following standard header records are required for t
This text is long and has been trimmed here. Open the source document for the complete record.
This is a copy of a public record, reproduced as it was published. It is not legal advice, and it may not be the version a court would rely on. Check the official source before you cite it.