January 2001 Minutes
IEEE
Storage System Standards
Working Group
(P1244)

Minutes
Meeting held January 16 through January 18, 2001
At the offices of Legato, Inc
Palo Alto, CA

Jack Cole, IEEE Sponsor
Curtis Anderson, SSSWG Chair; Alan Rollow, SSSWG Vice Chair

1244.1  Architecture/Data Model
        Geoff Peck (principal), Curtis Anderson, Joel Williams,
        Murali Sathyanarayana
1244.2  Session Security, Authentication, and Initialization Protocol
        Bruce Haddon (principal 2000-), Jan Klier (principal 1997-2000),
        Curtis Anderson, Joel Williams
1244.3  Media Management Protocol
        Murali Sathyanarayana (principal), Curtis Anderson, Joel Williams
1244.4  Drive Management Protocol
        Joel Williams
1244.5  Library Management Protocol
        Joel Williams
1244.6  Media Manager Interchange Protocol
        Joel Williams (principal), Curtis Anderson
1244.7  Media Manager Control Interface Protocol
        no current editor
1244.8  The C Language Procedural Interface
        Paul Lockwood
1244.9  MMS User Mount Commands
        Alan Rollow
1244.10 MMS Standard Administrative and Operational Commands
        Alan Rollow
1244.11 MOVER
        Joel Williams
New Features List
        Curtis Anderson

ATTENDANCE (5).

* Minutes from the November meeting were approved without change.

* The IEEE Mass Storage Conference (http://www.storageconference.org) will be held in San Diego from 4/16-4/20.  The group felt that their decision to attend the conference would not affect their coming to the SSSWG meetings, and that we have lots more work to do.  So, the schedule for the next two meetings was confirmed for 3/13-3/15 and 5/15-5/17.  Alan Rollow will will host the March meeting at the Compaq, Inc., facility in Colorado Springs, CO.  The May meeting will be held at a to-be-determined location in the Washington, DC, area.  The group will not hold a formal meeting at the Mass Storage Conference, but may get together informally to continue our work.

* 1244.6 "Data export/import" - Curtis added a first pass of the XML variant of the export structure to the document that Joel started.  He needs to create a Document Type Definition (DTD) for the XML and include both that and some more explanatory text into the document.  When that has been done, the group will do an email review and then put it into the queue to be balloted at the first convenient opportunity.

* 1244.8 "C Language API" - Paul is continuing to make progress on this. The group walked through the Paul's latest proposal and commented on it. Paul will be producing a revised version.  The level of comments given suggests that the next version might be the last one, that after that version, there will only be presentation nits before balloting.  Note again that this version will not include support for new features such as event notification.  1244.8 will need to be updated when those new features are included in 1244.1, 1244.3, etc.

* 1244.9 & 1244.10 "User and Admin CLI" - Alan presented the latest versions of these documents.  There was long debate on which approach to take to isolating unprivileged users from each other when they are using the mmsuser CLI tool to mount volumes.  One approach puts that responsibility on the mmsuser application while the other approach makes use of the authentication mechanisms already built into 1244.2.  The group felt that the relative merits end up favoring the former approach in spite of the seeming ease of the latter approach.  The "man page" for each command was looked over and comments made on the usability and power of each
proposed command.

* 1244.11 "Mover" - The made another discussion pass through Joel's updated Mover API.  Smaller changes were recommended than last time, the group is approaching completion of the API portion of this topic.  The API is intended to allow source-code compatibility across platforms.

The group debated whether we need to define an over-the-wire protocol to be used between Movers versus using an existing protocol that is "close enough" (eg: NDMP).  Only a rough consensus was reached, but it was felt that an external protocol like NDMP could be used even though a 1244.11 protocol would better support our needs.

+ We need to define the format for device handles generated by a DM so that the Mover associated with an application can decide which access method the handle is to be used with.  For example: "/usr/MMS/handles/KJHGSDFLKJ" is a local device node while "ndmp://host.domain.com:devicename" could be used to represent NDMP transport of the Mover's data stream.

+ We need to ensure the 1244 standard gets the appropriate label info from the MMS catalog to the DM so that the DM can verify the media's label at mount time.  Specifically, if the media has an IEEE 1244 label on it, the CartridgeID, SideName, and PartitionName from the MMS catalog must match the values stored in the on-media label.

+ When using an NDMP transport, we need to decide how to get the userid and password that NDMP's authentication mechanism requires to the Mover associated with the application.  Putting it into the device handle is problematic in that the device handle is visible to applications accessing the MMS catalog, and the handle passes (possibly unencrypted) across the network from MMS to application.

+ The Mover associated with the DM that does the mount-time verification of the label should not read the second label file.  The Mover associated with the application will read that instead.

+ It is the group's belief that removeable media drives accessed via the iSCSI protocol will appear to applications just like a drive that is attached via FibreChannel or parallel SCSI.  The operating system will provide device drivers that will make it so.  Thus, we can "ignore" iSCSI in the sense of not taking any explicit action to support it in the Mover standard, it will be supported just the same as any locally attached device is supported.

* The group received a presentation by Shaun Ellis, the Product Manager for Legato's SmartMedia product, on the current state and future plans for SmartMedia.  Since SmartMedia implements a structure that is a precursor to the 1244 standard, we are very interested in real world feedback on the problems that average users have had with the system.  The results were not a surprise to the group, configuring a 1244 MMS system is complex and without administrative aids the System Administrator must know quite a bit about how a 1244 system operates.  Configuring and administering Storage Area Networks is very complex in its own right and a lot of the demand for SmartMedia is in SAN installations.  The end result is the group's desire to put more emphasis on usability and support for configuration aids in future updates to 1244.

* Curtis has obtained copies of the final versions of the balloted standards in editable form from the IEEE Editor for 3 of the five balloted standards. He still needs to get the others.  Joel has volunteered some time to get the text formatting back into shape.  Changes to support the 1244.6-11 series of standards and changes to support the New Features will be added to the affected documents with "change bars" added to highlight them.  The result will be the group's working documents and will not take effect without passing through the next ballot of the standard.

* Futures List, "Session Disconnect/Reconnect" - No discussion.
* Futures List, "Event Notification Model" - No discussion.
* Futures List, "Central Configuration Management" - No discussion.
* Futures List, "LM-Based Drive Selection" - No discussion.
* Futures List, "Automatic Interlibrary Transfer" - No discussion.
* Futures List, "Fine Grained Security" - No discussion.

* Futures List, "Migrate Control" - The group decided that a new feature needs to be added to the next version of the standard that allows a privileged application to force control of a library or drive to move from one LM or DM to another one.  Prior to this, control would only move based on LM/DM failure or on the need to mount a cartridge (DM movement only). A new command is proposed for MMP:

migrate library['libname'] to['lmname'];
    or
migrate drive['drivename'] to['dmname'];

This command would force control of the indicated library or drive to move to the named LM or DM for that device.  This depends on the currently defined requirement that each LM/DM for a given library/drive have a unique instance name.  A nit in 1244.1 incorrectly claims that the LMName attribute of a library is a "control" field.

* Futures List, "Self Description" - The group decided that a new feature needs to be added to the next version of the standard that allows an application to "discover" the database schema.  Prior to this, an app would have to have that information (effectively) compiled in, it could not be obtained from the MMS itself.  A new attribute of the SYSTEM object is proposed.  It would be named "DBSchema" and it's value would encode the
structure of the database that the current MMS server supported.  The value is proposed to have the following structure:

<value> ::= <object>+
<object> ::= "text" "[" <object-name> <field>+ "]"
<object-name> ::= "APPLICATION" | "AI" | "BAY" | ...
<field> ::= "text" "[" <field-name> <field-type> <data-type>
<description> <default-value> <allowed-value>+ "]"
<field-name> ::= <string>
<field-type> ::= "key" | "characteristic" | "control" | "system"
<data-type> ::= "enum" | "number" | "string" | "timestamp" | "UUID"
<description> ::= <string>
<default-value> ::= <string>
<allowed-value> ::= <string>

For example:
    text["VOLUME"
text["CartridgeID" "key" "UUID"
    "Unique identifier for the cartridge" "none" "none"]
text["SideName" "key" "string"
    "The name of the side of the cartridge" "none" "none"] ]

Note that this is not intended as an openning for implementations to modify the schema of the MMS server, it is intended to allow administrative applications to be data driven rather than use compiled in information to deal with the MMS server's data requirements.  For example, creating an object of a given type requires certain information be provided by the application, and what is required depends on the type of object being created.  The new attribute enables administrative apps to be written that
can obtain those requirements from the MMS rather than having that info "compiled in".

* 1563.1 & 1563.2 "Tape Standards" - Paul noted that in his work with the NDMP working group (http://www.ndmp.org) they seem to be in need of standard tape access semantics like those proposed for IEEE 1563.  They are busy with finishing off version 4 of the NDMP standard for now, but he will continue to monitor their progress and when the time is right, we will begin talking about cooperative development of standard tape access semantics.

* 1563.3 "Tape Format" - No discussion.

* Related Standards Organizations - Alan gave an update on the SNIA's Technology Center at the Compaq facility in Colorado Springs.  It is huge and almost ready to open.  Curtis gave an update on the IETF's IP-Attached Storage Working Group (IPS).  After considerable progress on iSCSI, and considerable confusion over whether it was permissible for iSCSI to change the definition of TCP (it is not), there are now two factions debating whether to try to subsume iFCP into iSCSI or not.  iFCP bridges FibreChannel routing, control, and data flow protocols directly into IETF routing, control, and data flow protocols.  iSCSI effectively tunnels SCSI commands through an IP network to the other end, and has yet to address some of the more complex issues in routing and error recovery in a network context that FibreChannel has addressed.

* Evangelism: Bruce Haddon's article "IEEE Storage System Standards" (pages 8-16) was published in the December issue of the ACM Special Interest Group Newsletter "Operating Systems Review".  Curtis' contact information was given in the article for people wanting more information, and he will report the type and number of contacts that he receives to the group.


Next Meeting:
        March 13-15, 2001, Compaq offices, Colorado Springs, CO.

Future Meetings:
        May 15-17, 2001, in the Washington, DC, area.

Important links:
http://www.SSSWG.org - Our working group's web site
http://www.StorageConference.org - IEEE Mass Storage Conference
http://www.IEEE-SSSC.org - IEEE Storage Standards Steering Committee
http://www.SNIA.org - Storage Networking Industry Association

Active discussion continues on the above topics on the email reflector "work@ssswg.org".  Please subscribe if you are interested in hearing more by sending email to "majordomo@ssswg.org" with a body of "subscribe work".

SSSWG Home