ESI modifications proposed for revision 2.1

[Bob Snively]

* From the SCSI Reflector, posted by:
* Bob.Snively at Eng.Sun.COM (Bob Snively)
*

To:		Distribution

From:		Bob Snively

Date:		February 7, 1996

Subject:	Notes on ESI

The following issues were raised by a discussion of the
ESI document with Jim Coomes of Seagate.  I believe that
these changes are mostly editorial clarifications and do not
change theintent of the  text.  I will either make these corrections
or include them in the questions and issues and 
release a new modified version of this proposal before the
ESI meeting.

1)	Section 8.1 description of parameter truncation, P 4

The definition describing the truncation of parameters during
the execution of SEND DIAGNOSTIC will not work properly with
devices that pass ESI information through without knowing the
structure of the parameter list.  The valid approaches might be:

	a)	Require the page_length + 4 to be equal to the
		allocation length or else post a check condition.
		If they are equal, that is the length of transfer
		that will be performed.  If they are different,
		the transfer length will be the allocation length
		or the first 4 page bytes, whichever is shorter.
	
	b)	Allow the page_length + 4 to be any value and
		the allocation length to be any value.  Transmit
		the lesser or the page_length + 4 or the allocation
		length.  If the ESI information is invalid, this
		can be returned in a subsequent ESI status 
		page, probably as an informative condition.

I have modified the document to take the first approach.

Note that invalid pages can still be sent and valid short pages 
can still be sent, unless we choose to explicitly prohibit them 
and require the outbound pages to be precisely the length required
by the configuration page.  At present, I have not modified the
document to prohibit the use of invalid or shortened valid pages.

2)	Clarification of normal and short status pages

Table bb on page 9 defines the format of the normal (as opposed
to short) status page.  As a result, it implies that bits 
3-0 of byte 1 should always have the specified value.  To correct
this mis-impression, the title is changed to:

	Table bb - Normal enclosure services status page

In addition, the entry for bit 7 of byte 1 is modified to read:

	Short (=0)

3)	ESI operations for SFF-8045 drives always present short status

This is properly noted in most of the outbound pages.  For section,
8.1.6, it has been inadvertently omitted and will be included as it
was for the other sections.

4)	SCSI Bus described

The SCSI documents should not refer to the SCSI Bus, but rather to
a SCSI connection, since most SCSI devices will not be using a bus.
This must be corrected in section 11.1 and anywhere else it is found.

5)	Clarify use of ESI commands by non-ESI devices

The text of 11.1 and 11.2 does not make it perfectly clear that
there are really two different ways to access enclosure services.
They may be accessed either through an enclosure services
device type logical unit (having a device type of 0Dh as shown
in the response to an INQUIRY command) or through an enclosure
services command set (SEND DIAGNOSTIC, RECEIVE DIAGNOSTIC RESULTS)
on any other type of logical unit.  The text will be modified to
clarify this.

6)	Clarify error presentation differences for ESI and non-ESI devices

Section 2.4 presently does not distinguish that there are basically
two classes of errors.  One can be detected by ESI type devices and
involves lots of different abnormalities in the formation of the
ESI string.  A second can be detected by normal devices that transport
ESI strings to an ESI processor.  These have only to do with the
proper shape of the string, since the device does not parse the
string and verify its contents.  Section 2.4 will be clarified accordingly.

7)	Examine EFW requirements

It has been proposed that the EFW function be removed.  The basic problem is
that the management of the -PARALLEL ESI signal must change according to
whether or not the enclosure is an 8045 or an 8067 enclosure.  Once that
is done, it is then necessary to sample the EFW signal according to 
complex rules.  

It would be simpler to simply remove it and let the device take care
of itself, except for those disconnection management services that the
enclosure could legitimately provide. 

8)	Remove redundant EFW requirement

The last bullet of the final EFW mode is redundant and may be removed.


9)	Is it possible to ignore directives to the ESI function.

An additional discussion item was identified by Rod Dekonin of
Symbios.  He notes that some enclosure functions may nominally be
observable from device status and controlled by host actions 
to individual enclosure services type devices.  It is possible that 
RAID controller management of the enclosure or self-protective 
behavior of the enclosure may require that some other process over-ride the 
enclosure services control page functions.  It is also possible that
some functions are completely taken over by the RAID controller so that
control actions through the ESI command set are ignored.  I believe that
his interpretation is correct and that almost all ESI control entries
are optional and may be ignored, overriden, or re-interpreted by
the ESI services device or by other controllers that share the 
responsibility for managing the enclosure.  Several sections need
minor modifications to make this very clear.