SSSWG - May 1997 Minutes


SSSWG - May 1997 Minutes
----------------------------------------------------------------------------

March 1997 Minutes of the
IEEE Storage Systems Standards Working Group (Project 1244)
------------------------------------------------------------
   Meeting at Silicon Graphics Facilities
   Mountain View, CA, May 13-14, 1997

   Arranged by Mike Hardy, SGI

   Chair:  Jack Cole,    Model Editor:  Sam Coleman
   Documents Custodian & MCS Chair: Dixon Hutchinson
   Archivist:  Bill Wolfe, NASA/Langley Research Center

Attendance.
------------------------------------------------------------
   Curtis Anderson      SGI             curtis@sgi.com
   Carl Braganza        VERITAS         carl@veritas.com
   Jack Cole            ARL             cole@arl.mil
   Sam Coleman          LLNL            scoleman@llnl.gov
   Anat Gafni           VERITAS         gafni@veritas.com
   Mike Hardy           SGI             mhardy@engr.sgi.com
   Dixon Hutchinson     EXABYTE         hutch@exabyte.com
   Geoff Peck           SGI             geoff@sgi.com
   Alan Rollow          DEC             alan@nabeth.cxo.dec.com
   Eric Stouffer        IBM             stouffer@us.ibm.com
   Joel Williams        SES             joel.williams@ses-inc.com
   Tom Weimer           VERITAS         tom@veritas.com

Administrative.
------------------------------------------------------------

The meeting began at 8:30 am with the usual business of attendance and
registration. Minutes from the Boulder meeting in March were approved,
as was the agenda for this meeting.

General
------------------------------------------------------------

The NIST Advanced Technology Program was discussed, and it was decided
that getting a group together to respond would take more time than
remained before the NIST deadline.

The need to revise and renew all the SSSWG PARs (except for MCS) was
revisited, but it was recognized that revision would have to wait for
the re-scoping of the MSSRM components and terms.

Discussion continued from the previous meeting on OpenVault architecture
and MCS.

At the previous meeting, Geoff Peck was volunteered to work on renaming
and redefining components of OpenVault and the MSSRM to arrive at a
common set of terms, objects.  Geoff was not able to spend much time on
this, but he did develop some ideas, and presented these. This lead to a
long discussion which did produce some results. Geoff suggested that a
web page separate from the SSSWG's be established to carry on the
discussion by posting submitted ideas.  It is unclear whether this page
will be announced and open to all, or just to attendees, but Jack will
set up such a page with Geoff's notes from this meeting as the initial
material (same as handed out at the meeting).

Mark Epstein/SGI, described the current OpenVault database objects and
their attributes.

At the March meeting, Alan Rollow presented on MCS as a non-attendee,
and Dixon and Alan left that meeting intending to collaborate on MCS.
They did, and Alan presented the current take on MCS at this meeting.
Handouts and overheads will be added to the online documents available
at www.arl.mil/IEEE, and email will be sent to the reflector when they
are added. 

At the previous meeting, Joel made a motion, seconded by Sam,  that
would state by resolution that the SSSWG is taking a new direction in
merging ideas from OpenVault with MSSRM.  The motion wording was
heavily revised between meetings, and voting concluded at this meeting.
A copy of the motion is attached.  Of fifteen eligible voters, ten voted
in favor of the resolution (one with reservations), three were against
the resolution, one abstained, and one did not respond.  The motion
carried.  One vote against the resolution held the position that the
resolution was an endorsement of a particular vendor's product.  Two of
the votes against the resolution held the common position that this new
direction was unnecessary because the MSSRM is still a viable model.


THANKS TO....
------------------------------------------------------------
Anat Gafni for organizing and to VERITAS for sponsoring the January
meeting in Mountain View.

Dixon Hutchinson/EXABYTE for organizing the March meeting in Boulder.

Mike Hardy for organizing and SGI for sponsoring the May meeting in
Mountain View.


Next Meeting.
------------------------------------------------------------
15-17 July           Breckenridge, CO/Rich Wrenn

Future Meetings.
------------------------------------------------------------
10-12 September      Timberline Lodge, OR



ATTACHMENT
------------------------------------------------------------
THE MOTION --- APPROVED --- (PROPONENT:  JOEL WILLIAMS, SES-INC.)

RATIONALE.

The SSSWG recognizes the need for fresh ideas and approaches to its
efforts at designing generic storage systems in order to progress
toward its goals in a timely manner.

SGI participants have recently joined the WG with the desire to leverage
the existing WG expertise in development of the SGI OpenVault interface
as well as contribute to the revision of the MSSRM and components.

AND

OpenVault satisfies, in general, the requirements of the Reference
Model for the PVR, PVL, and MVR, although some aspects of the MVR are
not currently implemented.

BE IT NOTED THAT

The SGI OpenVault interface has the following desirable aspects:

(1)  It is a current implementation which has been tested to some degree
and demonstrated to the SSSWG and so is known to be practical.

(2)  It is still in its infancy, and so is not presented to the Working
Group on a "take-it-or-leave-it" basis, but with the understanding that
the interface will develop in the future.

(3) It is available for use by anyone at nominal fees and to
non-commercial endusers without fee.

(4) It does not contain requirements for other software which is not
also free, but can be interfaced with software which is not available at
nominal costs.

(5) It is designed to be platform independent.

AND

The SGI OpenVault interface departs from the previous thinking of the
Working Group in the following ways:

(1) It is implemented as a command language, application layer protocol,
over TCP/IP, as opposed to a C-language API over DCE.  If desired a
C-language API could be developed over this command language, once the
language is standardized.

(2) It approaches design of a generic storage system from a minimalist
view --- minimum features which should work must work, and further
minimal features are added as deemed appropriate.  The Working Group
approach historically has been to start by identifying all possible
features and attempting to throw a net around these.  This resulted in a
very robust model and components, but one which was not timely in
respect to implementation and standardization.  That is, too much
was attempted at one time to be practical.

THEREFORE BE IT RESOLVED

(1) Notwithstanding anything else in this resolution, the SSSWG
recognizes the need to change direction and to assimilate as many
outside ideas from all sources as practical in revising its MSSRM.

That the IEEE SSSWG shall work closely with participants from 
SGI and other sponsors to do the following and other things:

(2)  Develop a standardized command language for the three modules (PVR,
PVL, and MVR).

(3)  Develop standard data structures along the lines of the objects in
the current OpenVault data model.

(4)  Determine the point at which balloting seems appropriate for draft
standards and then for standards.  While OpenVault is not a target for
adoption as a standard, it is a starting point for change to the MSSRM.
But OpenVault itself is changing, and the Working Group will adjust its
Model and components to assimilate these fresh ideas and others from
participants. 

(5)  Approve related draft standards early in 1998.

IT IS ALSO NOTED THAT

(1)  The terminology in the current OpenVault implementation is not the
standard IEEE SSSWG terminology.  Some accommodation may have to be made
between the Working Group and the OpenVault terminology.  In addition,
new terminology and definitions may be needed which are not presently
embraced by either OpenVault or the MSSRM, and these will have to be 
suggested by SSSWG participants.

(2)  The practical limitations of the standardization process and the
software development process at SGI make it reasonable to set a single
future target for standardization and software releases, so that the two
processes will converge in a reasonable time.

(3)  The IEEE SSSWG invites participation by all, and the process which
produces the most viable storage system design is one which is based on
diversity of opinion.


SSSWG Home