SSSWG - May 1996 Minutes
Date: Fri, 17 May 1996 08:56:44 -0600
From: Dixon Hutchinson <hutch@exabyte.com>
To: ieee+mss@larc.nasa.gov
Subject: Minutes of May Meeting in Aberdeen
IEEE Storage Systems Standards Working Group Meeting
Minutes
May 7-9, 1996
Aberdeen Proving Grounds, Maryland
Attendance:
Jack Cole U. S. Army Research Laboratory
cole@arl.mil 410-278-9276
Dixon Hutchinson Exabyte Corporation
hutch@exabyte.com 303-417-7751
Merritt Jones The MITRE Corporation
Merritt@mitre.org
Dave Skinner Red Cape Softeware
Dave.Skinner@Redcape.com 303-604-0766
John Stephens Lockheed Grumman
stephj@herndon.grumman.com 703-713-4649
Hamid Vazire Hewlett-Packard
vazire@cup.hp.com 408-447-5420
Joel Williams Systems Engineering and Security
joel.williams@ses-inc.com 301-441-3694
Grant Woodside U.S. Design
gewoods@usdesign.com 410-381-3000
Rich Wrenn Digital Equipment Corp.
wrenn@cookie.enet.dec.com 719-548-2887
Tuesday May 7th, 1996
1. After introductions and brief discussions of topics for the day,
the meeting was movd from the Top of the Bay at Aberdeen Proving
Ground to the Conference Center in the APG Edgewood Area in order
to enjoy better meeting facilities which became available at the
last minute.
2. J. Williams presented changes to the PVR API since the last meeting.
a. Changes requested at last meeting were reviewed.
b. One change implemented is that events are now included in the API.
c. The opacity of handles was discussed.
d. The API is almost ready, and the consistency review will be
completed at this meeting. The API should be ready then
for an internal SSSWG vote. The URL for the API is:
http://206.233.193.50/pvrapi/PVR.contents.html
e. Action Item: Make the API available in 1) HTML over the net
(currently available), 2) FTPable HTML files for local perusal, 3)
Entire API in one postscript file. (Joel Williams)
3. Return to Handle discussion: Then consensus is that the handle is
opaque and that the definition of the handle is undefined in the API.
Anything that starts a task returns task ID's, not handles.
4. Lunch
5. Breakouts:
a. PVR-API work session with Wrenn/Williams
b. PAR development of:
"Standard Media Changer Service (MSC) API"
Wednesday May 8th, 1996
1. Breakouts:
a. PVR-API work session with Wrenn/Williams
b.
i. Discussion of goals of attendees
ii. Discussion of reasons why the IEEE model is not modeled
after OSI: Grant asked "why not leverage the OSI model for
OSSI?". Discussion related to the different nature of
storage systems, the need for simultaneous access to all
layers of the model, etc. Conclusion was that OSSI needs
updating or perhaps even re-writing. Further discussion
centered around finding a technical editor to lead the OSSI
V6 re-write-effort...Merritt indicated there might be a
volunteer available, but he needs to check further.
2. Detailed discussion on the scope of an OS independent API for robotic
control. We decided that the "Medium Changer Service (MCS) API" would
represent the set of commands available in the X3T10 (SCSI-2) Medium
Changer command set in API form., subject to the perspective of a
system-level API. The objective is to represent the SCSI-2 MC
commands with an API, however, there may be MC commands which are
inconsistent with the goal of providing a reliable, consistent system
API.
The first step in this effort is to develop a Project Authorization
Request (PAR) and receive approval from the IEEE's News Standards
Committee (NesCOM). In parallel, a white paper or rationale needs to be
developed to explain why this service/interface is needed, plus a
first cut at requirements, project management, schedule and
deliverables. With PAR approval and a completed rationale, a
"Marketing" compaign is needed to create awareness and interest in
participation.
Dave Skinner noted that the MCS API project represents a good
candidate for standardization by a group such at the SSSWG in that the
SCSI-2 MC is reasonably well understood, widely adopted and stable.
He noted that formal standards efforts have the best chances for
success when the subject matter is in such a state, vs. when a
standard attempts to "invent" technology or concepts.
3. Lunch
4. Business:
a. Future Meetings:
i. July 9,10,11: River Mountain Lodge, Breckenridge, CO.
Reservations by June 21; Hosted by Digital
ii. September 16 & 20 in coordination with Goddard Mass
Storage Institute.
iii. November 12, 13, 14: Cupertino, CA; Hosted by HP
b. IEEE SSSWG dinner, tonight at Bayard in Chesapeake City
5. Further discussion on the scope of the robotic interface
6.
Development of outline for the rationale of the development of the
Robotics API. The outline will be used to create a white paper to be
distributed before the July meeting. This white paper is to be used
to sell the IEEE Standards Activities Board on the PAR, and to sell
OSV's, ISV's and library vendors on the API.
Action Item:
Finish the White Paper (D. Hutchinson, G. Woodside, D. Skinner)
Thursday May 9th, 1996
1. Discussion on what is needed to complete the PVR-API for voting.
Complete man-pages and documented header files are almost done...what
else is needed?
2. Breakouts:
a. PVR-API work session. Wrenn/Williams
b. Robotic API White Paper Outline development.
3. Meeting concluded by 6pm
--------------------------------------------------------------------------
The following is the scope and Purpose from the PAR developed for the
Media Changer Service
--------------------------------------------------------------------------
Scope:
To specify a complete, operating system independent, software
interface for devices modeled on the SCSI medium changer command set,
including, but not limited to, tape and optical automated libraries.
This interface encompasses all media changer functions: media
movement, media identification, resource management, changer status,
and vendor specific operations.
Purpose:
To provide an enabling technology for software clients of media
changer devices. For example, IEEE SSSWG Physical Volume Repositories
under development by IEEE SSSWG (P1244.3).
SSSWG Home