SSSWG - January 1995 Minutes
IEEE Storage System Standards Working Group Meeting
10-13th. January, 1995
Marriot Residence Inn, Sunnyvale.
Attendance:
Bob Baird
Jack Cole
Anat Gafni
Bruce K. Haddon
Wayne Hurlbert
Andy Hanushevsky
Creig Humes
Joel Miller
Gary Mueller
Michael T. Peterson
Rich Ruef
Dave Skinner
Robyne Sumpter
Hamid Vazire
Bill Watson
Rich Wrenn
General Session, Tuesday 10 January, 9.00 a.m.
Chair: Dave Skinner.
Recording Secretary: Bruce K. Haddon.
Agenda
======
Announcements
Organizational Issues
* Meeting "discipline", agendas, etc.
* Meeting Schedule
* Publicity
* Treasurer
* Recording Secretary
POSIX Status
PVL Discussion
Subcommittee Status
Tabled Items
Review of action items
Proposed agenda for 95/3 meeting
Other Business
1. Announcements
=============
* Literature available:
Brochures on "MEDIA MANIA! The Fundamentals and Futures of
Removable Mass Storage Media" by Linda Kempster
PVL Task Model (draft), supplied by Mike Peterson. Not a
formal submission but rather an informative of work in
progress.
* Mike Peterson, Chair, PVL Committee: PVL committee will
distribute over the next three meetings a model and API for
PVL. Introductory paper available and distributed at this
meeting. Proposed that this be discussed during meeting.
Will be available on "swedishchef". Rich Wrenn suggests
accepting the "style" for the API.
* Jack Cole will be presenting at the NASA Goddard Mass Storage
conference on the progress of the IEEE SSSWG: he wants and
needs input from each chairman of each of the subcommittee
regarding progress in the last year.
2. Organization Issues
===================
* Meeting "discipline", agendas, etc.
Bruce Haddon proposed: within each 3 1/2 day meeting, a General
Session, General Technical Session, Committee Breakouts, Summary
session (Progress, review of action items, next meeting agenda,
V6 OSSI RM.)
Jack Cole commented that there is a need to show "strawman"
standards by the time of the MSS. Hamid Vazire said target
milestones are needed. Bruce Haddon and Michael Peterson noted
that we need to record progress. Rich Wrenn and Gary Mueller
discussed the need to publish progress.
Discussion centered for some time around the need to preserve and
improve attendance. There appears to be a longer term trend of
people leaving: perhaps because V5 has been "finished", and this
was many people s objective. Better publicity of objectives,
agendas, meeting times and places may help.
Dave Skinner asked whether it was tenable to produce just, say
PVR, or PVR and PVL, and set a later schedule to committee s.
Rich Wrenn noted that Storage System Management is a problem, and
is hardly operating at the moment. Jack Cole noted we are
competing with "MIC" and other "management" standardization
efforts. Rich asked consideration be given to making progress
without waiting for or depending upon work on the SSM committee.
Some note was made of "end-of-life" of SSSWG.
Subsequent discussion ranged over many related issues of why
people attend, what economic value may be served by the
standards, value of the SSSWG API s, vender and customer
interests, and whether there are viable competing storage models.
Dave Skinner proposed:
Publish / distribute the following:
- SSSWG Business Plan (overall objectives for the three key
dot groups, V6 progress, etc.)
# Action Item: Dave Skinner and Jack Cole will draft this
by Wednesday, 11 January.
- Subcommittee Management Plan
- Draft standards, work in progress
- Notes, Minutes,
# Action Item: Dave Skinner and Jack Cole will propose
meeting procedure by Wednesday, 11 January.
V6 Progress
Is a V6 needed? Almost everyone agreed with Rich Wrenn
that V5 is not useful other than naming the components of
the model. V5 does not fully address all issues, nor even
provide close guidance to the generation of the
standards. He noted to do a V6 needs a "chief architect"
to determine consistency, not just an editor. This was
enthusiastically agreed by Bruce Haddon. Other points of
view were expressed none of which positively rejected
having a V6.
# Action Item: this is to be an agenda item for decision on
next meeting.
In above discussion, noted need to replace "swedishchef"
as an anonymous ftp site.
# Action Item: Dave Skinner to find or provide such a
replacement.
Meeting Schedule
================
* Dates for 1995
Jan 10-13: Marriott Residence Inn, Sunnyvale. (Done)
Mar 14-17: DEC, Colorado Springs (Host: Rich Wrenn).
May 16-19: (tentatively Valley Forge, Pennsylvania. Host:
Rich Garrison)
July 18-21: (tentatively DEC, Seattle, by Michael
Peterson)
Sept. 14-15 (Monterey, at the end of the MSS)
Nov. 7-10 (TBD)
* Dates for 1996 (partial list)
Jan (towards the end of the month)
June (MSS is in Annecy, France).
* Treasurer
A new treasurer is needed.
* Recording Secretary
# Decided: Will be rotated each meeting, a volunteer to be
sought at each previous meeting.
3. POSIX Status
============
# Action Item: Dave Skinner will report POSIX status, and make
available copies of PAR s on interacting areas (by end of this
meeting).
4. PVL Discussion
==============
A document entitled "PVL Task Model and API Reference" was made
available by Michael Peterson to the attendees. His purpose was to put
the SSSWG on notice that DEC intends to make a concrete proposal for PVL
along the lines contained in the document. He invited discussion and
response to this document, as a way of making progress on the definition
of the PVL.
At this meeting, the discussion should center around the task model. At
the next meeting, the security model will be presented, and at the July
meeting, a draft of the actual PVL API.
A question asked by Michael was: what is the process for getting from an
offered draft to a balloted standard.
# Action Item: a process is needed for "internal" balloting within
the SSSWG. This process is needed in order for the SSSWG to reach
consensus on the draft which is to be submitted to IEEE
balloting. Jack Cole to review charter and make a proposal (by
next meeting).
A discussion then ensued that considered the form, style, and syntax of
the document. This brought up a number of other issues that impinge on
the other components and the overall style of the Storage System
Standards. The effects of this discussion will be reported separately.
(The meeting was adjourned at 6.00 p.m., and resumed at 8.30 a.m.,
Wednesday, 11 January, 1995).
The first discussion concerned notions of "consistency", and how
consistency can be achieved by storage system clients. The consensus was
for the availability of a transaction-style (begin/end, open/close,
start/stop) bracketing of operations, with access specified (exclusive,
read only, write/read permitted, etc.). Such rights must time out
eventually, unless renewed appropriately.
The next discussion concerned the "style" of the API, whether the name
of the function should encode the responding component, the object type,
the verb, and a "predicate" (e.g. attribute name or attribute set),
versus, perhaps, a style where one or more of these values appeared
encoded in a parameter or parameters, where the parameters may represent
lists.
A question of performance arose, which led to the question of whether
the application programming interface was in 1-1 correspondence with the
"wire" protocol. A long discussion then ensued on the so-called "plug-
and-play" requirement, viz.:
Plug and Play Requirement:
The ability to ship X-level (e.g. PVR, PVL) products that can be
installed by customers that will work with (X+1)-level (e.g.,
PVL, or respectively, VSS) products when the X-level product
complies with X-level standard and a "profile".
a) Customer should be able to do this with multiple X-level
products from multiple vendors simultaneously;
b) Customer should not have to compile and link the (X+1)-level
product to make this happen; and,
c) The customer should not have to shut down the (X+1)-level
product to add the X-level product.
(The last two conditions, b) and c), were later conceded to be of
lower importance than a).)
The discussion lead eventually to the following:
## Resolved: that the decision (made in Las Vegas?)to standardize on
the use of DCE RPC for all component interfaces be re-considered,
and that the issue not be redecided until the March meeting.
Moved: Michael Peterson; 2nd, Bob Baird.
Motion withdrawn by mover and seconder.
The reason for withdrawing the motion was that subsequent discussion
pointed out the DCE RPC requirement was a "profile" item, not an
absolute requirement, hence the motion addressed a non-problem.
## Resolved: that the syntax of the API all component interfaces be
specified in a form that uses a switch structure so that the
profile of choice can be implemented.
Moved: Bob Baird. Motion failed for a second.
The bottom line out of the discussion was that the following two issues
are important:
1) consistency of interface "style" for all model components; and,
2) performance of the interface for "set" and "get" ( = "show") for
large sets of attributes.
Bob Baird presented an alternative to the interface style that had been
presented earlier by Michael Peterson. Details of this can be obtained
from Bob upon request.
3. POSIX Status (continued)
============
Dave Skinner presented the recent PAR s approved for POSIX that may
affect the SSSWG work (particularly PVL and MOVER).
The first is a proposal to amend P1003.1 (Part 1: System API Revisions--
Removable Media Support), and reads as follows:
Scope: This standard will refine the behavior of open(), close(),
read(), and write() as they pertain to removable serial
media. Adds new API s to position serial media. This work
may expand the list of errno s to include those
pertaining explicitly to removable media. This work
embodies existing common practice.
Purpose: The purpose of this work is to standardize the set of
API s to position serial removable media and the current
behavior of the commonly used I/O functions.
The second is a proposal to amend P1003.2 (Part 2: Shell and Utilities--
Removable Media Support), and reads as follows:
Scope: Insert the definition of "mt" into P1003.2. This
command/utility provides the functionality to position
serial media and status of the device.
Purpose: The purpose of this work is to improve the P1003.2
document by including a utility used in common practice.
(The general session of the meeting was adjourned at 6:20 p.m., and will
resume at 8:30 a.m., Thursday, 12th January.)
5. Subcommittee Status
===================
* PVL
Chairman: Michael Peterson.
1 active member currently
During last 1 1/2 years
- Model components drafted for review
- Schedule proposal
Task object (presented this meeting)
Security (March)
Draft API (July)
Concerns
- Charter of the committee as a whole
Discussion: the committee as a whole needs to "approve" a
draft from a subcommittee before it is distributed for
review to the larger MSS-TC and IEEE readership for
comment.
- Design
Discussion: design efforts should take place in
subcommittee, but there is a need to set up a method to
create the consistency requirements.
- Set/review of requirements
Discussion: there is not a real method to explicitly set
requirements, particularly the "consistency" requirements
which have not been documented.
- Vote and approve drafts
A more general discussion ensued concerning the method of
running the work of the committee. This discussion was
tabled for consideration after the subcommittee reviews
* VSS
Chairman: Bob Baird
Has been working on a document, tele-working with Rich Garrison.
The work done by Rich Garrison and Nathan Walsh at the last
meeting has yet to be incorporated. Bob has material that can be
placed on an ftp site for informational distribution.
A draft for committee consideration will be distributed in June
for consideration at the July meeting.
* PVR
Chairman: Dave Skinner
The draft intended for this time, for a number of reasons, is not
ready. A new commitment will be forthcoming by the end of this
meeting. John Peake, the technical editor, has had to leave the
SSSWG due to company commitments, and a replacement is yet to be
named.
* MVR
Chairman: Creig Humes
Attendance at meetings has been good. Participation between
meetings has not been as good. The HPSS "mover" has been taken as
a model, and this is being modified and simplified. The actual
written work is not in shape for review at this time, but July is
a realistic time frame.
* Environment/OID
Chairman: Andy Hanushevsky.
This is a committee of one, but Andy has lost funding for
continuing, hence will become a committee of zero.
The only reasonable candidate for an environment that fulfills
all the requirements and is commercially available is DCE. "UUID"
is a reasonable candidate for the OID, although as it includes a
"type", which not proposed in the model for the OID.
6. Tabled Items
============
## Resolved: that the committee adopt a "lightweight" RFP process,
for implementation at a later meeting.
Moved: Michael Peterson, 2nd: Andy Hanushevsky
Discussion: Voting members for the purpose of this and any other
resolution were those who were in good standing, having attended two
out of the last six meetings, in accordance with the resolution made in
1992. To pass, a majority of those in attendance and eligible to vote
is needed. (Although is did not affect the voting at this meeting,
because the numbers were not closed enough, a query arose as to the
interpretation intended on the "2 of 6" requirement: is it "2 of the 6
previous meetings", or "2 of 6 meetings, including the current one"?)
Motion passed unanimously.
Discussion:
Recognized need for a submission process, naming conventions, etc.
Suggested that RFP s be distributed via the reflector, and that RFP s be
sponsored by the committee or a subcommittee chairman. A working group
will examine further questions of lifetime, size, logging, and the
evaluation process.
# Action Item: Dave Skinner and Jack Cole will be the working group
to define this process, and submit to the reflector by 27th
January.
Suggestions for RFP's to be issued:
OID (Bob Baird)
"Plug and Play"
Requirements for cross-model consistency (covering e.g.,
Base types, (Michael Peterson, 95/1/26)
Criteria
Entry-point naming conventions / argument naming
conventions,
API calling conventions (argument passing) (Dave Skinner)
Exception handling / Error propagation (Creig Humes)).
Format of submissions:
Current ftp site is swedishchef.lerc.nasa.gov (which may change).
Directories:
"/masstore"
"/anyone" (writeable, send Betty-Jo email to have
submission moved).
Acceptable formats:
Required for all submissions (just the words): ASCII text
w/ line breaks (CR/LF).
Optional (particularly if there are graphics) PostScript
(paper size independent, please).
## Resolved: acceptable formats include ASCII text with line breaks
(CR/LF) and PostScript. Submissions should include both formats,
unless the submission includes no graphics, in which case
PostScript is optional.
Moved: Rich Wrenn, 2nd: Michel Peterson.
Discussion: Bob Baird questioned the need for both, but general
consensus was that ASCII is needed.
Motion passed with no dissent.
7. Review of action items
======================
Two action items to be amended.
Item 1 and item 2 to have date of 31st January, 1995.
8. Proposed agenda for 95/3 meeting
================================
General Session
Announcements
Minutes of the previous meeting
Treasurer s report
Review of Action Items from previous meeting
Status of recruitment and sponsorship.
Status of RFP s.
Discussion of Proposal for a Version 6 OSSI Model.
Presentation and discussion of the PVL Security Model (Michael
Peterson)
Presentation and discussion on API style (Rich Wrenn)
Presentation and discussion of overview of VSS (Bob Baird)
Subcommittee Sessions
Closing General Session
Subcommittee status (each Chairman)
Tabled Items
Review of Action Items
Proposed agenda for 95/5 meeting.
Other business.
## Resolved: that this proposed agenda be accepted.
Moved: Bruce K. Haddon, 2nd: Rich Wrenn
Passed unanimously.
If no other person takes the rotation, Bruce has volunteered to serve as
recording secretary for the March meeting.
9. Other Business
==============
## Resolved: That there be a discussion be held this afternoon on
the PVL Task Object.
Moved: Rich Wrenn, 2nd: Bruce K. Haddon
Withdrawn by the mover and seconder.
## Resolved: That there be a discussion held this afternoon on the
syntactic and semantic consistency requirements for the
components of the standards.
Moved: Michael Peterson, 2nd: Bob Baird.
Passed unanimously.
Topics:
There must be consistency amongst API s
Extent of imposing consistency (e.g., PVL vs. MVR)
Are we really defining API s (vs. service interface)
What is the proper degree of "coupling" (i.e., interdependency)
between model components
Discussion:
* There must be consistency amongst API s
Is "look and feel" a real requirement?
Advantages: Faster learning curve, less time looking at manuals,
common programming paradigm for management applications, code
reuse between component implementations, smaller client code
particularly in management applications, smaller amounts of
documentation.
Note that these advantages imply semantic consistency (common
objects for common things, e.g., task objects as shown in the PVL
draft) in addition to syntactic consistency.
Disadvantages: extra coordination effort and discussion
requirements between subcommittees, takes more time, management
issues, possible performance on implemented system.
Performance may override syntactic consistency requirements, but
maybe not semantic consistency.
Bob Baird took the other view, that consistency is only needed
when components share clients, e.g., VSS is a client of PVL, and
PVL is a client of PVR, but VSS does not see PVR, so has no
requirement to see consistency between PVL and PVR.
It would only make more work to call a "task" a "task" in one
component, a "job" in another, a "request" in third.
* Extent of imposing consistency (e.g., PVL vs. MVR)
Is consistency inherently a good thing? The POSIX standards show
inconsistencies, but this does not seem to have impeded progress.
Bruce Haddon coined the term "gratuitous inconsistency" (i.e.,
inconsistencies that arise for lack of attention), and Bob Baird
agreed that we should avoid gratuitous inconsistency.
As examples: representation of time, representation of strings
(e.g., counted 16-bit UNICODE vs. null terminated ASCII).
* Are we really defining API s (vs. service interface).
Yes, we are really defining the API, was the consensus. It was
also agreed that the implication of this is that an
implementation of a component service means supplied a something
that implements the service itself and a something that
implements the API on each desired client.
* What is the proper degree of "coupling" (i.e., interdependency)
between model components?
Bob Baird believes that the "coupling" should only be a function
of the use of the interfaces of a second component by a first
component. An example of another coupling is the use of common
services, say, time. He asks that such other couplings be
minimized. A statement was offered that the correct place for
collecting these things is in the environment definition. The
"profile" for the environment is not part of the standard, but
essentially specifies which options within a standard are being
used (or, as mentioned by Michael Peterson, have been tested).
Another of the purposes of the profile is to remove technology
dependencies from the standards.
10. Close of Meeting
================
The meeting was adjourned at 4:45 p.m., 12th January, 1995.
SSSWG Home