Proposed response to Sun comments on SAM Rev 12

Charles Monia, SHR3-2/W4, 237-6757, 03-Jan-1994 1754 monia at
Mon Jan 3 14:53:57 PST 1994

From: Charles Monia
      SAM Technical Editor

To: Members of X3T9.2

Subject: Proposed responses to Sun Microsystem Comments on SAM, Revision 12

The following are SAM review comments received from Sun Microsytems.
Proposed responses are denoted with a right arrow ">". Comments
with no response are proposed for inclusion as specified.

Charles Monia

Begin proposed responses

E 001  	Page 9 and 10, Section 1.0

	The reference document identifications should be completed,
	including at least the official title and project draft number.

E 002  	Page 11, Section 3.1.11

	The sentence should be corrected in the area: "command has than has

E 003	Page 16, Section 3.1.9

	The word "word" should be re-examined.  If all goes well, a
	search throughout the document will reveal that the word
	is either never used or can always be replaced with something
	like "4-byte value", avoiding ambiguity.

E 004	Page 16, Section 3.3

	From context, it appears that lower case is used both for
	words having their normal English language meaning and for
	words other than SCSI commands, statuses, and acronyms.  The
	last sentence should either be deleted or the distinction between
	lower case and upper case significance made clear.

E 005	Page 23, Section 4.2.1 and Page 33, Section 4.7.1

	Page 23 indicates in the next to the last paragraph that an
	application client controls one or more tasks.
	Page 33 indicates in the definition of application client that
	there is one application client for each task or pending
	task management function.

	It is my impression that there is a one-to-one relationship
	between application clients and tasks and that each new task
	is created by a new instance of an application client.  That
	would make page 33 correct and page 23 incorrect.  This should
	be clarified in both locations and corrected in one.

> The text will be modified to make the one-to-one relationship clear.
> References to the control of multiple tasks will be deleted.

E 006	Page 24, Figure 4

	Figure 4 uses a layering model which does not refer
	to the layering terms defined immediately below it.  I believe
	that the LLP and ULP terms should be properly assigned to the
	figure. That either requires relabeling or may require that
	the central layer be broken into a ULP layer and an LLP layer.

> Agreed.

T 007	Page 31, Section 4.6

	The last paragraph of section 4.6 indicates that the service
	delivery transactions are received in the order in which they
	are sent for a given pair of source and destination devices.
	Fibre Channel and some other channels allow the proper operation 
	of SCSI with out of order delivery of command information.  This
	restriction should be modified to allow the out of order
	delivery of commands if operating system or channel conventions 
	can guarantee the proper behavior of the scsi targets.  As an
	example, ordering of groups of commands can be enforced by
	the host adapter function or by management of individual commands
	with respect to the acknowledgment processing of commands
	requiring ordering.

> I had assumed that, while data may arrive out of order, the receiver
> would restore ordering before presenting the data to the consumer.
> I am concerned that relaxing the ordering requirement in the manner
> suggested will lead to implementations that break existing host code which
> depends on the implicit ordering provided by SIP/SPI.
> I would like to reopen this issue at the next working group.

E 008	Page 33, Section 4.7.1

	Shouldn't the Initiator equation be:

		Initiator = 0{Application Client} + 1{Initiator Identifier}1

	If not, a considerable amount of additional information is
	required to indicate what the rules are for the execution of
	tasks across multiple independent ports.

> Multiple identifiers should be considered as nothing more than
> an alias for the same physical entity.
> I would like input from the working group on this issue. According
> to past feedback, multiple identifiers for the same entity were
> considered acceptable.

E 009	Page 34, Section 4.7.2

	Shouldn't the Target equation be:

		Target = 1{Logical Unit} + 1{Target Identifier}1

	If not, a considerable amount of additional information is 
	required to indicate what the rulse are for execution of
	tasks to a LUN having multiple target ports within a single task.

> See reply to comment 008.

T 010	Page 35, Section 4.7.3

	LUN 0 should always exist, at least to the point of being able
	to respond to TIO, INQUIRY, and REQUEST SENSE.  The LUN need
	not be installed.

> Agreed.

T 011	Page 36, Section

	The Task Set should have only one Untagged Task per initiator
	according to previous definitions.  The definitions in this
	document allow more than one, since an untagged task can also
	have an identifier.  If it has an identifier, isn't it tagged?

> The identifier for an untagged task does not included the tag parameter.
> Thus, by definition, an initiator cannot request the creation of more
> than one untagged task per logical unit without causing a duplicate
> task I/D.

T 012	Page 37, Section

	The last sentence implies that the only mechanism known at
	the service layer and at the communication level might be the
	Task Identifier.  In fact, the Task Identifier known at the
	service layer may have an arbitrary mapping to the 
	Task Identifier information actually passed across the
	protocol interface.  As an example, CAM knows a service
	request by the pointer to the CAM Control Block, but a
	SIP implementation uses the initiator identifier, target
	identifier, LUN, and Tag to perform the identification of
	the same IO Process.  This should be clarified.

> The implication was intentional.
> Commands such as copy require the application client to have 
> explicit knowlege of the target identifier and logical unit number
> used by the protocol.

T 013	Page 39, Section 6

	The Data-In Buffer Pointer is an input accompanying the
	Execute Command, not an output.  It identifies the buffer
	that will be used when the Data In Delivery Service is

> The convention for denoting inputs and outputs will be modified to
> distinguish between a container to receive an output and
> the output itself.

T 014	Page 39, Section 6 and page 74, Section 9.1

	The Autosense Data, as an output arguement, is not defined
	elsewhere.  In particular, it is missing from the definition
	of section 9.1, the Confirmation returned to the Application
	Client.  The referenced clause should be defined.

> The autosense return flag indicates whether or not sense data was
> returned to the autosense buffer. Input from the working group is
> is needed to determine the conditions under which autosense data
> is to be returned. ie. Can autosense data be returned for any command
> or only those which complete with a status of CHECK CONDITION or
> If the latter, then this flag is unneccesary.

T 015	Section 6 and Section 9

	The Command Model and the Service Model appear to be
	partially uncorrelated and redundant.  I would suggest that
	Section 6.1 be replaced by Sections 9.1 and 9.2, with appropriate 
	complementary information retained from section 6.1. That would
	become a new section 6.

	I would then suggest that section 9.3 be moved to become
	the new section 7.  

	The sections 6.1 - 6.6 would become the new section 8 and
	section 7 would be renumbered to section 9.

	This would restructure the document to present the
	model information in conjunction with the service model
	that implements it.

	A summary of the chapter titles would be:

	5:	Procedural model for commands and task management functions

	6:	SCSI Command Model and Services

		6.1:	Data Transfer Services

	7:	SCSI Task Management Model and Services

	8:	SCSI Command and Protocol  

	9:	Task Set Management

	10:	Task Management Functions

	If this cannot be done, a great deal of editorial work must
	be done to show the relationship between the Command Model
	and the Service Model and to correlate them.

> The document will be restructured to resolve the inconsistencies
> mentioned.

E 017	Page 39, Section 6

	The Autosense Return Flag should be labeled the Autosense
	Returned Flag.
> Agreed.

E 018	Page 40, Tables 1, 2, and 3.

	Using unjustified, uncentered, courier type would make this
	work better.  Alternatively, it should be presented using the
	table functionality of the word processor.

T 019	Page 43, Section 6.3

	Status is also not presented after Abort Task and Abort Task Set.
T 020	Page 47, Section 6.4.2

	In the execution of linked commands, step 5, the accessing of
	the second command, is normally created by actions of the
	target.  This is especially obvious in SIP, where the
	target manages the command phase of the second command directly.
	It is also true for SBP, where the target fetches new commands
	from initiator memory and for the FCP, where initiative is passed 
	to the initiator to enable the output of the command information.

> The document will be modified to state that the manner in which the
> next command is solicited is protocol specific.

T 021	Page 48, Section 6.5.1

	The Programmable Operating Definition is not a characteristic
	of SAM or of any protocol.  It can actually be used to influence
	only those things that are visible at the command set level, and
	so should only be described in the command set.  In particular
	(ref paragraph 2), the SCSI compliance level, SCSI specification
	level, and other parameters should be explicitly banned from
	changing, since these parameters reflect details like 
	the use or non-use of an Identify message, the use of extended
	Identify messages, and the width of data transfers, items which
	may extend into the requesting and the responding services.

	Among the other parameters which should not be changeable 
	are included:  

	Vendor Identification:  Changing this parameter allows fraudulent
		replacement of disk drives with non-conforming disk drives.

	Vendor Serial Number:  Changing this parameter allows fraudulent
		warranty repairs to be sought.

	The technical solution to this problem is to remove the
	section from SAM and to place it in the appropriate section
	of the SPC document.  The CHANGE DEFINITION command should then
	be described in such a manner as to prohibit modifications
	to anything other than command level behavior and to
	prohibit modifications that create the opportunity for fraud.
> This section will be moved to SPC in its entirety.

T 022	Page 48, Section 6.5.1

	The text, when taken over to SPC, should contain a precise
	indication of the state of the machine necessary to accept
	and execute a CHANGE DEFINITION command.  That state should
	be that no tasks for any initiator are present in the task
	set of the logical unit.  This can be accomplished by reserving
	and quiescing the logical unit through normal command set 
	operations.  The CHANGE DEFINITION command should be rejected
	if any tasks are in the task set for the destination LUN.

	The text, when taken over to SPC, should contain a precise
	indication of when the new definition becomes active.  It
	should become active at the time that the service response
	indicating successful completion of the CHANGE DEFINITION command
	is transmitted from the LUN.  
> These matters should be addressed to the SPC technical editor.	

E 023	Page 49, Section

	The definition of "hard reset" should be documented.

> Agreed.

E 024	Page 50, Section 6.5.3

	According to Annex C and SCSI-2, the proper response for
	overlapped commands should be a sense key of "ILLEGAL REQUEST",
> The correction will be made as specified above.

E 025	Page 50, Section 6.5.4

	Item B, typo:  "unti" should be "until"

T 026	Page 52, Section 6.5.7

	It should be clearly indicated that AEN is an optional behavior,
	both by the target and by the initiator.  While a protocol is
	required to architect the capability, no device should be
	required to implement the capability.

> Agreed.

T 027	Page 52, Section 6.5.7

	In the last paragraph of the page, the text indicates that
	AEN should be reported only once per occurrence of the causing
	event.  In fact, for errors that are generic and may influence
	the operation of any attached initiators, the AEN should be
	presented to all attached initiators.  The text should
	be modified to clearly indicate that AEN should be offered only 
	once to the initiator related to the command causing the
	failure, but is allowed to be offered to every initiator if
	it is unclear to the target which initiator will be affected by
	the failure.
> I believe this requires discussion by the working group at large.

T 028	Page 52, Section 6.5.7

	AEN is defined in SCSI-2 as sharply limited in its capabilities.
	It is always executed as an initiator-to-target operation, where
	the target is identifiable through the INQUIRY command as a
	Processor Type device.  The information is sent as a SEND
	command to LUN 0 of the device.

	In particular, AEN SEND cannot be generated to a target
	that identifies itself as other than a Processor Type device
	because the command overlaps the decode of a WRITE(6) in
	other command sets.

	Text should be installed in section 6.5.7 describing this
	characteristic of AEN.

> Since the current specification makes it clear that the delivery
> mechanism for asynchronous event reporting is protocol-specific, I
> believe no further information is required.

E 029	Page 53, Section 6.6

	The events, items a-h, should include additionally those
	unitemized events in the first paragraph, including 
	TARGET RESET, hard reset, and power-on reset.

> Agreed.

T 030	Page 54, Section 7.1

	The definition of "current task" and therefore "pending task" 
	varies somewhat from the definition contained in Annex C.  
	In Annex C, the current task
	is defined as a task that is moving data to or from the physical
	transport, meaning in the case of disk drives and tapes, that
	data is being moved to or from the magnetic storage medium.
	In fact, the term "current task" is not used in section 7
	and should probably be dropped.  Of the three terms used,
	only one has meaning in the clarified task management structure,
	and that is Ordered Blocking Boundary.  That term should probably be
	moved into section 7.2 and section 7.1 should be collapsed out
	of existence.

> I believe the definition of current task in annex C refers to a task
> that is actively transferring data over the physical interconnect.
> Anyhow, in discussing this matter during the last plenary, it was decided
> that SAM should require each protocol standard to define the concept of a
> "current task".

E 031	Page 54, Section 7.2

	First paragraph, undetermined information missing in second

E 032	Page 55, Section 7.2

	"All Previous tasks complete" event needs to be clarified.
	In particular, it cannot occur for simultanously enabled tasks
	and is only true at ordered blocking boundaries.

> "Previous tasks" are all tasks that are older than the task in
> question. In view of that definition, it's not apparent to me where
> the problem lies.

E 033	Page 55, Section 7.2

	The definition of the QErr bit must be obtained from
	SPC and installed here, since it is not clear what meaning
	it will have without it's being defined.

> Agreed.

T 034	Page 55, Section 7.2

	Task abort should include other causes of task termination, 
	including hard reset and power on reset.

> Agreed.

T 035	Page 55, Section 7.2

	There does not appear to be a state for tasks that are
	on-going behind the scenes, including immediate commands
	and tasks that have been aborted as far as the SCSI
	interface is concerned, but are continuing on to completion
	to bring the logical unit to a known state.  These may not
	actually be treated as tasks, but rather as peer applications
	started by tasks.  In any case, mention of their allowability
	should be made in section 7.2.

> I believe the scope of SAM must be limited to describing
> required task behavior that is visible to the application client.
> In that regard, once a task abort completes, the task ceases
> to exist as far as the initiator is concerned.
> While the peer processes you describe may be relevant to the
> internals of specific target implementations, I don't think
> SAM should have anything to say about them. 

T 036	Page 57, Section 7.3

	Restricted reordering appears to be defined incompatibly with
	SCSI-2.  In SCSI-2, the restricted reordering only requires that
	the final value of all data observable on the medium shall have
	exactly the same value as it would have if the commands had been
	executed in the same received sequence without using tagged
	queueing (which in SCSI-2, meant "received synchronously".)
	SAM appears to require the execution in precisely the specified
	order in the case of restricted reordering.  This is an overly
	strict requirement and should be modified to the SCSI-2 definition.
	As an example, that means that READ operations having the
	SIMPLE task attribute performed under restricted ordering may 
	be executed in any order.  

	This must also be corrected in paragraph 2 of page 58, same section.

> This material is incorrect and will be deleted from the specification.

E 037	Page 57, Section 7.3

	The state diagram applies to each single task, but does not
	express the relationship among tasks.  This should be clarified
	in the title and explanations.

> Agreed.

E 038	Page 58, Section 7.3

	The last paragraph before Table 9 has a typographical error in the
	last sentence.  The word "be" should be deleted.

T 039	Page 58, Section 7.3

	The restrictions on head of queue task enabling are more correct than
	those in section 7 of Annex C, which are probably unenforceable.

T 040	Page 59, Section 7.3

	The second sentence of the last paragraph may be overly general.
	The CLEAR ACA should only abort tasks if the QErr bit is set to

> This should be discussed at the next working group. The description
> in the specification reflects inputs from others in the
> working group.

T 041	Page 60, Section 7.3

	During an ACA condition, only properly offered ACA tasks are
	enabled.  All other tasks are rejected.  This is not made
	clear in the text or table.  

	Alternatively, it may be required for a task to enter the
	enabled state for it to be rejected.  If this interpretation
	is correct, the state diagram should be modified to contain it.

> According to the model, the task is created by the target, then tested
> to see if it can be accepted into the task set.
> The specification will be amended to clarify the above.

T 042	Page 61, Section 7.4

	The examples pertain only to those LUN's having a queue management
	capability.  It is also possible that typical tape drives,
	sequential data delivery devices (voice recorders, etc.), mechanical
	devices (like media changers), and certain other devices may
	not allow tagged queueing at all.  In this case, the SAM
	should absolutely not force the devices to perform queue management,
	but rather should allow the synchronous delivery of the tasks
	under control of the initiator's application client.  

	This is allowed almost everywhere, but an example should be included
	in section 7 to demonstrate that it is allowed.

	In particular, such devices have a slightly different behavior
	with respect to overfilling their very restricted task set.  A
	second task will be treated as an overlapped command, rather than
	a Task Set Full condition.  This must be made clear in
	sections 6.3 and 6.5.3.

> Agreed.

T 043	Page 63/64, Section 7.4.2

	It is not clear that tasks 4,5, and 6 should be enabled before task
	7 (a head of queue task) is completed.  I would not expect any
	new tasks to be enabled until all head of queue tasks are done.
	See step 3 in the sequence.

> According to the queuing model (92-141R8):
> "Any Task that was accepted into the task set before a
> Head Of Queue Task may complete before the Head Of
> Queue Task completes."

T 044	Page 67, Section 7.4.4, step 1

	The text should read:

	1)	Since restricted ordering is in effect, simple task 1
		can be enabled.  If the effects of enabling simple task 2 would
		cause a violation of the restricted reordering 
		algorithm, it must remain dormant until simple task 1 is

	It is likely that, if both simple task 1 and simple task 2 are
	read operations on a disk drive, they can both be enabled and
	still meet the restricted ordering requirements.

> The inclusion of Restricted Reordering into the queuing model is
> in error. All references in SAM will be deleted.

T 045	Page 68, Section 8

	SIP only provides an indication that the task management function
	has been delivered, not that it has been completed.  It is
	possible that the Function Complete service response is
	stepping beyond the original definitions from SCSI and should
	be softened to an accepted delivery indication.
> The bus free following successful delivery of the last message byte is the
> SIP/SPI completion indication.

T 046	Page 70, sections 8.2 - 8.7 
	(Modification required to change vote to affirmative).
	It is clear from the document that each protocol shall
	be required to provide a mechanism to perform each of
	the task management functions.  In addition to this,
	it must be made absolutely clear which of the task 
	management functions are optional for a SCSI device
	to implement and which ones are required.  Some task
	management functions may only be required if certain
	other optional capabilities are allowed.

	Terminate Task is an example of a function that is always optional.

	Clear Task Set is an example of a function that is only required if
	the task set elects the definition:

		Task Set = {0(Tagged Task) + 0(Untagged Task)}

	Clear Auto Contingent Allegiance is an example of a function
	that is only required if the ACA bit is allowed to be set to one.

	These are probably best placed in a new paragraph under each
	Task Management Function entitled "Service Response"

	A typical case would be for Terminate Task:

	Service Response:

	Function Complete:	Indicates Terminate Task Function was accepted
				and will be attempted by Device Server
	Function Rejected:	Indicates Terminate Task Function not
				implemented by Device Server
	Failure:		Indicates Terminate Task Function could
				not be delivered to Device Server

	A contrasting case would be for Clear Task Set:

	Service Response:

	Function Complete:	Indicates Clear Task Set Function was
				accepted and will be attempted by Device Server.
	Function Rejected:	This response is only allowed for Device
				Servers that reject all Tagged Tasks.
	Failure:		Indicates Clear Task Set Function could not
				be delivered to Device Server.

	Table of desired optionality:

	Task Management Function	Opt/Rqrd	Conditions

	Abort Task			Rqrd

	Abort Task Set			Opt		Rqrd if Tagged Tasks
	Clear ACA			Opt		Rqrd if ACA bit = 1
	Clear Task Set			Opt		Rqrd if Tagged Tasks
	Target Reset			Rqrd
	Terminate Task			Opt		

> This issue needs to be discussed at the next working group.
> Others are of the impression that support for tagged queuing
> is mandatory for all devices.

T 047	Page 70, section 8.2, 8.3

	Should the Abort Task or the Abort Task Set function including 
	a task with the ACA attribute also abort the ACA condition?

	At present, the answer is it should not be.	
> That is correct. The following excerpt from 92-141R8
> specifies the conditions under which an ACA shall be
> cleared
>  "The Auto Contingent Allegiance Condition shall be cleared
>  after:
>  -a power on condition,
>  -a Clear Auto Contingent Allegiance Task Management request
>   issued to the logical unit by the initiator receiving the
>   Check Condition or Command Terminated status error.
>  -a Target Reset Task Management request
>  The Auto Contingent Allegiance shall not be cleared for any
>  reason other than those listed above."

T 048	Page 70, section 8.2

	What should the Device Server do if an Abort Task for a task
	with a certain task identifier overlaps or arrives shortly
	before the task with that task identifier?  There is some
	uncertainty about whether the new task is the one to be
	aborted or is indeed a new task that is not to be aborted.
	This is theoretically possible with certain drivers and out-of-order
	delivery fabrics.

	I would suggest that any task with the specified identifier
	be aborted if it arrives at the device server any time from before 
	the task management function arrives until the service response
	from the task management function is transmitted by the device
	server.  Any identical task after that time should be considered
	a new task.  A recommendation that task identifiers be maintained
	unique for some time period after completion of the task would
	make this requirement more robust.

> In my opinion, the behavior specified in SAM should be based on a
> sequential delivery model. An SDS implementation
> may, of course, do what it likes provided the behavior visible to
> application clients, device servers and task managers is sequential.
> See the reply to item 007. 

T 049	Page 70, section 8.4

	When does the Clear ACA take effect?  I propose that it becomes
	effective immediately upon the arrival of the Clear ACA request.

> Agreed.

T 050	Page 71, section 8.5

	The phrase "All data for all terminated tasks shall be cleared."
	is ambiguous.  I assume that this includes both state information
	and the contents and identification of data buffers.  In particular,
	if a WRITE operation was active when a Clear Task Set was taking
	place, the data that had been transmitted to the disk, even if
	incomplete, would be the data returned by a subsequent READ.  The
	buffered data, even if incomplete, would not be returned by the READ.

> Since it is effectively impossible for an initiator to know the
> exact point at which a task was aborted. the present wording is
> is adequate, in my opinion.
> I suggest discussing the matter further during the January Working
> Group.

T 051	Page 71, Section 8.6

	The definition of hard reset is not present in the SAM document.

> A definition for hard reset will be added.

T 052	Page 71, Section 8.6

	In SIP, the target address, rather than the Logical Unit,
	is the destination of a TARGET RESET function.  It is
	probably reasonable to change the definition to LU Identifier,
	but this is definitely a change in the structure of SCSI.
	I would further propose that for those devices having
	a hierarchical Logical Unit structure as described in the
	RAID model, that the TARGET RESET be defined to reset not
	only the specified Logical Unit, but all Logical Units
	depending from that Logical Unit in the hierarchy.

> The model will be changed to define a single task manager per target.
> The Target Reset function will then require only the target
> identifier.

T 053	Page 72, Section 8.7

	The definition of corrupting the medium should be clarified.
	In particular, none of the Abort functions are expected to
	stop so quickly that incorrect CRC is written on the recording
	medium.  All of the functions, including Terminate Task,
	leave the medium in an ambiguous state in that the operation
	is incomplete.  Properly implemented, Terminate Task could
	provide the necessary information to make it possible for the
	host to determine the nature of the medium corruption, but
	cannot avoid the corruption.

> The reference to "media corruption" will be replaced with:
> "The TERMINATE TASK" function is invoked by the application client to
> terminate the specified task and return its state of completion."

 054	Page 72, Section 8.7

	In the third paragraph, item 1, there is a discussion of the
	residue of an allocation length or parameter list under the
	conditions of a Terminate Task.  Terminate task has some
	meaning with respect to data transfer tasks, where there
	is a long operation which will be interrupted.  For tasks
	that are instantaneously executed or which require the 
	complete parameter list for execution (MODE SELECT and 
	similar commands), the meaning of Terminate Task should
	be clarified.  I believe that the command should either
	not begin execution or should complete execution regardless
	of how many bytes have been transferred.  

	If the task completes successfully, it should not indicate 
	TASK TERMINATED status, but should indicate function complete
	(GOOD status).
> Trying to define the termination policy as you've suggested seems like
> a can of worms to me.
> I believe the decision as to how a given command is to be terminated is
> best left to the implmentation. ie. Let sleeping dogs lie.

T 055	Page 73, Section 9.1

	The SCSI Command Request may be excessively restrictive by
	defining a closed-ended list of request parameters.  Is it
	implicit that a protocol private input and output parameter
	list is allowed, or should it be explicitly allowed.

	This is also a valid question for the indication, response,
	and confirmation paramters.

> The goal of the architectural model is to specify behavior in a way
> that's protocol-independant. Adding protocol- or implementation-specific
> parameters in the manner suggested above will seriously compromise
> that goal and make it impossible to write portable software or
> firmware.
> In my opinion, compromising portability will seriously jeopardize the
> industry's significant software and firmware investment. Failure to
> protect that investment will discourage migration to newer technologies.

T 056	Page 73, Section 9.1

	I would have expected the Data In Buffer Pointer and the
	Autosense Buffer Pointer to be inputs to the requests, since
	they are pre-allocated areas that are being made known to
	the executor of the services at both ends of the link.

> The noation needs to be modified to identify pointer variables which receive
> outputs from a remote procedure call

T 057	Page 73, Section 9.1

	The autosense data returned in the area defined by the
	Autosense Buffer Pointer may include protocol dependent
	wrapper information and status in addition to the sense data.

> Allowing for such implementation-specific "wrapper" information
> is outside the scope of SAM and is not needed to adequately
> describe essential, protocol-independant behavior.
> See also the response to comment 055.

T 058	Page 75, Section 9.2

	The application client's buffer is not actually "a single,
	physically contiguous block of memory".  It is actually
	a contiguous block of virtual memory or a logically contiguous
	block of memory.
> The buffer will be defined as a "logically contiguous" block of
> memory.

T 059	Page 75, Section 9.2

	The device server is described as "must have the ability to
	transfer such data in increments smaller" than the total
	extent to be transferred.  In fact, there is no such
	requirement, but should be reworded to indicate:

	"The model also requires that the protocol be capable of
	transferring data in increments smaller than the extent
	specified in the command descriptor.  The device server
	may have the requirement to transfer data in such smaller

> Agreed. The change will be made as specified above.

T 060	Page 75, Section 9.2

	In the definition of Command Byte Count, it should additionally
	be clarified that verification of complete and correct
	information transfer may be impossible when data transfer
	segments overlap.  A protocol should be allowed to prohibit
	overlapped transfers.

> Agreed. As discussed during the working group review, SAM
> will also be modified to recommend that device servers wishing to
> retain portability, not attempt such overlapped transfers

E 061   Page 76, Section 9.2.1

	Third line, missing comma.

T 062	Page 76, Section 9.2.1

	The last sentence of the section is incorrect as written.
	The initiator should assure that the the blocks of data
	are written into the buffer at the correct displacement 
	within the buffer, regardless of the order in which the
	blocks were actually presented to the interface.

> No, the data must be written in the order received. Otherwise, an
> overlapping transfer that's written out of order will result in
> corrupted data.

T 063	Page 76, Section 9.2.2

	The Device Server Buffer Pointer is managed by the
	Device Server making the request and is not necessarily
	an input or output parameter of the request.

> As noted above, the notation must identify caller-supplied pointers
> that reference input or output data.

T 064	Page 76, Sections 9.2.1 and 9.2.2

	The transfers should not be considered successful unless
	the number of bytes transferred exactly matches the
	requested byte count.  In the case of a write, an
	incomplete byte count can only occur in the block transferring
	the highest offset byte of data and indicates an incorrect
	length, which must be posted back to the SCSI initiator
	according to the rules for incorrect length.  In the
	case of a read, such a mismatch in byte count is an error
	in the transfer process.
> The data transfer services always move the number of bytes
> requested. In the case you mention, the device
> server would invoke the service with an appropriately adjusted
> byte count then terminate the request appropriately.
> Failure to transfer the specified number of bytes is a fatal
> error within the service delivery subsystem.

T 065	Page 77, Section 9.3

	This section appears to be redundant with section 8.
	See problem 15.

	The "result" parameter codes disagree with those
	defined in Page 68, section 8.
> Any discrepancies will be corrected in the reorganized version.

T 066	Page 78-81, Annex A

	This section should be removed from the standard.  It offers
	nothing to the definitions of the standard.

	It does, however, point out that there is some information
	missing in the definition of task set.  I suggest that the
	information from Table 1 of annex C be included in the
	normative document, probably in section or section 7.

> While the information in the body of the standard must agree with the
> technical requirements set forth in the queuing model, the editor must
> have the latitude to select the clearest method of presentation.
> In that regard, I consider table 1 as illustrative material that
> supplements normative behavior described elsewhere.
> In my opinion, therefore, inclusion of table 1 is subject to editorial
> discretion.

E 067	Page 82-85, Annex B

	This section should be removed from the standard.  Subsequent
	updates should be documented with an appropriate cover letter
	to the draft standard and not within the standard document

T 068	Page 86-94, Annex C
	(Modification required to change vote to affirmative).

	This section is redundant with and disagrees with the
	normative standard.  It must be removed from the standard.
	It does not contain the necessary information about 
	the management of tasks during the various states, information
	which is correctly included in the draft.

	The following problems indicate information discrepancies
	and describe an appropriate correction for each discrepancy.

T 069	Annex C

	The description of the ACA control bit in Annex C is
	incomplete and has been correctly supplanted by the normative
	information contained in the body of the draft.
T 070	Page 87, Annex C, section 1.1

	"The target shall manage....all other task sets." is the
	information that should be transferred to section as
	described in problem 066

T 071 	Page 87, Annex C, section 2.1

	This section is not correct and is supplanted by the draft.

T 072	Page 88, Annex C, section 2.1.4

	"If the target accepts ...  complete the current task." is
	correct information not presently explicit in the body of the
	draft.  It should be added to section 8.4.

> As I interpret this text, a CLEAR AUTO CONTINGENT ALLEGIANCE issued
> with no ACA in effect is a NOP.
> I believe the description in clause 8.4 on page 72 covers this case.

T 073	Page 89, Annex C, section 2.2

	The list of task terminations may be an appropriate addition
	to section 7.  Section 7 is a little vague about the mechanisms
	by which a task is ended.

> Agreed.

T 074	Page 89, Annex C, section 3.1

	The second paragraph indicates that more than one current
	task may exist at a time.  This really means that more than
	one task may be enabled (and therefore in some state of
	execution) at one time.  

	The third paragraph indicates that more than one task may be
	actrive on a physical transport system at once.

	While implicit in the body of the draft, it might be helpful 
	to make these points explicit, possibly in section 7.3.

> Agree.

T 075	Page 91, Annex C, Table 1

	The information contained in this table should be included
	in section or section 7 as proposed in problem 66.

> Agreed.

More information about the T10 mailing list