Response to Comments on SBP-2 Revision 1f

John Nels Fuller jfuller at microsoft.com
Mon Nov 25 23:27:01 PST 1996


* From the SCSI Reflector (scsi at symbios.com), posted by:
* John Nels Fuller <jfuller at MICROSOFT.com>
*
Just one comment on item 3 below:  I don't think that SBP-2 should have
any verbiage that says that a password is interpreted as characters,
especially ASCII characters, as is implied by "padded with spaces."  It
should be up to the initiator and/or command set as to whether they are
interpreted as characters or binary numbers, an 8-character ASCII
password is less secure than a 64-bit pass code.

>----------
>From: 	PJohansson at aol.com[SMTP:PJohansson at aol.com]
>Sent: 	Thursday, November 21, 1996 6:34 PM
>To: 	scsi at symbios.com
>Cc: 	Stephen_Finch/SSI1.SSI1 at notes-gw.tus.ssi1.com; diskboys at dt.wdc.com
>Subject: 	Response to Comments on SBP-2 Revision 1f
>
>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