Response to Comments on SBP-2 Revision 1f

PJohansson at aol.com PJohansson at aol.com
Thu Nov 21 18:34:05 PST 1996


* From the SCSI Reflector (scsi at symbios.com), posted by:
* PJohansson at aol.com
*
To the X3T10 SBP-2 ad hoc working group and to interested X3T10 participants:

Embedded below are responses to Steve Finch's comments on SBP-2 Revision 1f.
Steve's original text is bracketed by << and >>.

Regards,

Peter Johansson
X3T10 Technical Editor, SBP-2

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson at aol.com

++++++++++++++++++++++++++++++

In a message dated 96-11-21 12:17:00 EST,
Stephen_Finch/SSI1.SSI1 at notes-gw.tus.ssi1.com (Stephen Finch/SSI1) writes:

++++++++++++++++++++++++++++++
<<  
 1.  I concur with all changes contained in Peter Johansson's
 email titled "SBP-2 Revision 1f Errata", which was based upon
 changes suggested by John Fuller.
>>

No comment...   :^)
 
 ++++++++++++++++++++++++++++++
 << 
 2.  In section 5.1.4, table 2 (page 30):  this table shows
 that only the value "4" as "Command set-dependent".  At the
 last meeting, the group decided to make "4-6" "Command set-
 dependent".  I would like to make all of these values as 
 command set dependent because we may need additional 
 management ORB values for controlling things like Power
 Modes in command sets such as Tailgate.  <Note:  this has
 the change in the table as underlined, but no change bar
 on the side.)
 >>

Command sets don't need more than one code set aside. There is ample code
space in the 32-bytes allocated to a management ORB to describe as many
supplemental (or extended) functions as needed by command sets. No change
made to the document.

 ++++++++++++++++++++++++++++++
<<  
 3.  In section 5.1.4.1, the paragraph on "password and 
 password_length".  I think the interpretation of these
 fields is command set dependent.  One point is that the
 use of password as an immediate value need not dependent
 on password_length being zero.  I think it would be 
 very beneficial for Tailgate to have up to 8 immediate
 data bytes of password and the number that are considered
 to be valid to be specified in the password_length.
 
 I suggest the following wording:
 
 "The password and password_length fields may specify optional, 
 command set-dependent information used to validate the login 
 request. The password field may contain immediate data,
 specify the address of a buffer which contains the password,
 may be ignored, or may be used for other purposes depending
 upon a command sets implementation.  If the password field is
 defined by the command set as being an address of a buffer,
 the password_length shall specify the size of that buffer and
 the buffer shall be accessible to a Serial Bus block read 
 request with a data transfer length less than or equal to 
 value contained in password_length. The format and usage 
 of password data, whether immediate or indirectly addressed,
 are beyond the scope of this standard.  The use of the
 password_length field in cases other than the case when the 
 password field contains a buffer address may be defined as 
 desired by the command set."

 Basically, if SBP-2 says its command set dependent, let the 
 command set use it as it desires and not have SBP-2 put 
 arbitrary restrictions on usage of these fields.
>>
 
I am, in general, opposed to the reintroduction of security into the SBP-2
protocol. I think our decision to leave it to the command sets was and is
correct. I plan to make an alternate proposal which would render the password
fields in the login ORB unnecessary. None the less, if a change has to be
made to something as ubiquitous as the login ORB I think its interpretation
should be common to all command sets.

With this in mind, I thought that an eight-byte password, period, was very
much in the spirit of NO OPTIONS! that has caught our fancy of late. For a
particular application, its easy to describe that user passwords less than
eight characters are padded in their least significant characters with
spaces. When the password is immediate, is there really any need to specify
its length?

If the consensus is that a length descriptor is necessary, I would prefer to
adopt the sort of scheme that John put into the tailgate document: password,
password_length and an immediate bit that indicates whether or not the
contents of password are a pointer or the password itself.

My recommendation is to leave the wording as it is.

++++++++++++++++++++++++++++++
 
 4.  In section 5.2, in the unlabeled table (page 39):
<<  
 The table was initially confusing to me but, after some
 meaningful amount of eye strain and neck twisting, I figured
 it out.  I suggest that some change in format could make 
 this more readable, but the contents are correct.
>>

Editorial. Deferred; no change made to the document proposed for
stabilization.
 
 ++++++++++++++++++++++++++++++
<<  
 5.  In section 8.2.1, item "a)", contains a reference to a 
 "lock transaction".  This should be "write transaction".
 >>

Done in Revision 1g.

 ++++++++++++++++++++++++++++++
<<  
 6.  In section 8.2.1, item "d)" doesn't have the constraint
 of the "for the logical unit".  I suggest:
 
 "d) If an active login_descriptor exists for the requested 
 logical unit has the exclusive attribute set, the target shall 
 reject the login request; and"
 >>

Changed as follows in Revision 1g:

"d) If an active login_descriptor with the exclusive attribute exists for the
lun specified in the login ORB, the target shall reject the login request;
and..."

 ++++++++++++++++++++++++++++++
<<
 7.  In section 8.4, (page 67), change:
 
 "A target shall reject a logout request if the source_ID of 
 the write request used to signal the logout ORB to the 
 MANAGEMENT_AGENT register is not equal to the 
 source_ID of the current or reconnected login."
 
 to:
 
 "A target shall reject a logout request if the source_ID of 
 the write request used to signal the logout ORB to the 
 MANAGEMENT_AGENT register is not equal to the 
 source_ID of the current or reconnected login or if the 
 login_ID field does not contain the value returned at 
 login to the initiator requesting the logout."
 >>

Changed as follows in Revision 1g:

"When an initiator no longer requires access to a target’s resources, it
shall signal a logout request to the management agent. The login to be
released shall be identified by login_ID in the logout ORB. A target shall
reject a logout request if login_ID does not match that of any active
login_descriptor or if the source_ID of the write request used to signal the
logout ORB to the MANAGEMENT_AGENT register is not equal to the source_ID of
the matching login_descriptor. If any tasks..."

 ++++++++++++++++++++++++++++++
 <<
 8.  In section 10.4.1, (page 79) the second bullet item 
 (indicated by "-") states that the aborted ORB shall be 
 completed with a status of REQUEST ABORTED.  Yet section 
 5.1.1 (Dummy ORB) states that the request shall be 
 completed without error.  This is a conflict!  I suggest 
 that section 5.1.1 be changed to require a REQUEST ABORTED 
 status be returned for Dummy ORBs.
>>

I agree. The last paragraph of 5.1.1 now reads as follows:

"Barring catastrophic target failure, dummy requests shall complete with a
status of REQUEST ABORTED. This is the normal completion status for an ORB
whose rq_fmt field is equal to three; it is not an error."

The sentence "In typical usage, a dummy ORB is initialized with a null
next_ORB pointer." no longer seems to belong in this paragraph so I moved it
to the preceding paragraph that defines the next_ORB field.
 
 ++++++++++++++++++++++++++++++
 <<
 9.  In section 10.4.1, (page 79) contains the following:
 
 "If the target supports the ABORT TASK function in task 
 management ORBs and the ORB identified by ORB_offset 
 has been fetched, the target shall perform the following 
 actions:
 
 a) The target shall not issue data transfer requests for 
 the task;
 
 b) The target shall wait for responses to pending data 
 transfer requests;
 
 c) If the task has not completed, the target shall store 
 completion status with a request status of REQUEST ABORTED 
 in system memory. If the task completed before the abort 
 task request was received, then the target has issued a 
 write request to store the completion status in system 
 memory. In either of these cases, the target shall wait 
 for the transaction complete acknowledgment or response.
 
 d) When all of the above events have completed, the 
 target shall store completion status for the abort task 
 request in the status buffer provided. The completion 
 status shall indicate FUNCTION COMPLETE."
 
 I have a real problem with this scenerio.  The problem is
 "when does the Abort Task catch up with the command being
 aborted?"  In SCSI, the answer is that the target may try
 to catch up and may or may not be able to.  The wording we
 have above contains a lot of "shall's".  Well, I always 
 interpret "shall's" as "must", and I can't/won't conform
 to the above.  And I don't want to be non-compliant....
 
 I suggest replacing the above with:
 
 "If the target supports the ABORT TASK function in task 
 management ORBs and the ORB identified by ORB_offset 
 has been fetched, the target may attempt to abort the
 task perform the following actions:
 
 a) The target should stop any additional data transfer
 transactions by
   i)  not issuing additional data transfer requests for
       the task; and,
   ii) waiting until all responses for outstanding data
       transfer requests to be received
 
 b) If the task has not completed, the target shall store 
 completion status with a request status of REQUEST ABORTED 
 in system memory. If the task is completed as it would have
 if the ABORT TASK had not been received, the target should
 store the completion status associated with the original
 command in system memory instead of a status indicating 
 REQUEST ABORTED. In either of these cases, the target shall 
 wait for the transaction complete acknowledgment or response
 associated with the sending of the status.
 
 c) When all of the above events have completed, the 
 target shall store completion status for the abort task 
 request in the status buffer provided. The completion 
 status shall indicate FUNCTION COMPLETE."
 >>

The heart of this matter seems to be whether or not there is any guarantee to
the initiator about responses (or lack thereof) that may be expected by an
initiator subsequent to a FUNCTION COMPLETE returned for an ABORT TASK
management request. If the ORB to be aborted has not been fetched, the
initiator knows that only one more response is expected from the target:
REQUEST ABORTED at some future time when the ORB is fetched. If command ORB
has already been fetched, all bets are off: the target may issue an
indeterminate number of data transfer requests or accesses to the page table
or even store completion status for the request. The question is, "Is the
return of FUNCTION COMPLETE to the ABORT TASK request a guarantee that no
MORE of these other requests will take place?" That's how it's written right
now, which is causing Steve a compliance problem.

The requirements for ABORT TASK, as it is implemented for a task management
ORB, could be reworded as shown below. These changes would place some
additional implementation burdens on some command sets and architectures,
such as SCSI, that wish to utilize the facilities of SBP-2. The burdens would
fall on code that executes at the initiator. The changes can be interpreted
as standing in opposition to our stated goal to be command-set neutral:
neither friendly nor unfriendly to any particular command set. I am uncertain
whether I endorse the language that follows, but I do think it is a clear way
to express what Steve is seeking. Comments?

"Targets may optionally support task management ORB’s with a function of
ABORT TASK. Targets that support abort task in this manner shall store a
completion status of FUNCTION COMPLETE for the abort task request in the
status buffer provided.

If the task to be aborted, identified by ORB_offset, is not recognized by the
target as part of its local working set, one of two conditions may exist:
either the ORB has not been fetched or completion status has already been
stored. In either case the target is not required to take any immediate
action. In the first case, when the ORB is ultimately fetched, the rq_fmt
field has a value of three and the target shall not execute the command. The
target shall store completion status for the aborted ORB; the request status
shall be REQUEST ABORTED. In the second case, no action whatsoever need be
taken by the target.

If the task to be aborted is recognized by the target as part of its local
working set, the target should attempt to abort the task according to the
steps below. Note that timing conditions may exist that prevent targets from
aborting the specified task. In particular, if the target has already issued
a write request to store completion status for the task to be aborted, the
target shall take no other action in response to the abort task request.
Otherwise, the target should perform the following actions in response to a
task management ORB with the ABORT TASK function:

a) The target should not issue additional data transfer requests for the
task;

b) The target shall wait for responses to pending data transfer requests and,
once all such responses are received, shall not issue additional data
transfer requests for the task; and

c) The target shall store completion status for the task to be aborted and
shall wait for the transaction complete acknowledgment or response. If the
target successfully aborted the task, the request status stored shall be
REQUEST ABORTED.

Regardless of which abort task methods are supported by the target, the
initiator shall not reuse the system memory occupied by the ORB, data buffer
or page table of the task to be aborted until completion status is returned
for that ORB."

 ++++++++++++++++++++++++++++++
<< 
 10.  A general comment/question:  in section 5.3, there is
 a table on page 41 (near the end of the section) that 
 contains error codes for use in the sbp_status field.  
 The question is:  are there other possible error codes 
 that we want to add here?
>>
 
Yes, but no one has taken the time to reexamine the structure / usage of the
eight bits available to us in the sbp_status field. It's still on my "things
to do" list but of uncertain priority.

 ++++++++++++++++++++++++++++++


*
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com




More information about the T10 mailing list