Proposed responses to Comments on FCP Revision 8

Bob Snively Bob.Snively at eng.sun.com
Thu Apr 14 17:27:15 PDT 1994



		PROPOSED RESPONSE TO BALLOT COMMENTS


The editor proposes the following responses to the ballot comments
made on Revision 008 of the SCSI FCP (X3T10/993D).

Those comments relating to all parts of Clause 6 are not addressed.
They will be analized after the study of the PRLI/PRLO 
functions as defined by FC-SB.


Comments generated by FSI:


1	Grammar

Comment:
Foreword, Line 2, Change "command," to "commands,".

Response:
The text is correct as written, specifically referring to
"SCSI command, data, and status information".  No change will be made.

2	Correct scope 	 

Comment:
Introduction, Para. 1, Line 3, Change "performance serial" to
"performance Fibre Channel".

Response:
Accepted.

3	Edit Introduction  

Comment:
Introduction, Para. 2, Line 1, Change "Sequences" to
"Exchanges and Information Units".

Response:
Accepted.

4	Edit Scope (Technical)

Comment:
Section 1 Scope, Para. 1, Line 1, Change "Upper Level Protocol (ULP)"
to "mapping protocol (FC-4)".

Response:
Accepted.

5	Edit References (Technical)      

Comment:
Section 2 Normative References, Delete reference to SCSI-2 Standard. 
It does not apply to this standard.  Only SAM applies.

Response:
The SAM document is the standard which the FCP is architected
to implement.  However, since its models are in large part
compatible with SAM, are architecturally well understood, and
complete those parts of the SCSI-3 document series which are
not yet available, it is a valid reference and will be retained.
Portions referenced from SCSI-2 include the format of REQUEST
SENSE information and the use of certain link signaling conventions.

6	Edit References

Comment:
Section 2 Normative References, Update Revision Level on FC-AL to 4.2.

Response:



7	Edit References

Comment:
2 Normative References, Update Revision Level on FC-FG to 2.1.

Response:

8	Edit References

Comment:
Section 2 Normative References, Update Revision Level on FC-SB to
proper level.

Response:

9	Information Units

Comment:
Section 3.1.12, Line 2, Change "a single sequence"  to "an".  The
Fibre Channel committee has requested that FC-4s not
mention sequences, except in a passing manner.  Information
Units are to be referenced and Exchanges.

Response:
The definition will be modified to make it more consistent with
the FC-PH, specifically Annex S which clearly identifies the
relationship between sequences and information units.
"FC-PH service interface:  a confirmed peer to peer service
requested by the upper layer protocol that requests the transfer of
a single information unit.  In the absence of an FC-3, the
transfer of an Information Unit by an FC-4 corresponds to the
transfer of a Sequence by FC-PH.  The services are listed 
below. [FC-PH, Annex S]"

10	Sequences

Comment:
General, as in Comment 9, Delete all references to the term
Sequence unless absolutely required to explain Fibre
Channel structure.  The term "Information Unit" is to be used
instead.

Response:
Accepted.  
4.1, para 3; 4.2, para 3; 4.2, para 4; 4.2, para 7; 4.3, para 2;
Table 4, title; 7.1, para 2 are effected.

11	Service Interface (Technical)     

Comment:
Section 3.1.12, Paras. 2, 3, 4, and 5. Delete.  Move to an Annex or
leave as a reference to FC-PH, but delete details from the
Glossary of terms.  The confusion about ULPs and FC-4s in
Comment 4 is evident in these paragraphs as well.

Response:
This appears to be the most appropriate location for the tutorial
function that points to the appropriate documentation in FC-PH.
The information is used in section 5.4.
The rewording of the definition (Comment 9) should correct any
confusion.

12	FCP I/O Operation

Comment:
Section 3.1.13, Delete sentence 2.  The explanation in the second
sentence is not part of the SAM definition.  This
definition needs to delete the "FCP" in its name.  The
definition is the SAM definition for an I/O operation and is
not unique to FCP. 

Response:
The SAM defines an I/O Operation as an operation defined by an
unlinked SCSI command, a series of linked SCSI commands, or a
task management function.  Within FCP, the I/O operation takes
on the additional meaning of those information unit transfers and
other activities that are performed across the Fibre Channel
to implement a SAM I/O Operation.  A SAM I/O Operation has
beginning and end conditions that are time independent and
interface independent.  An FCP I/O Operation has timing conditions
that indicate commencement and completion of the operation.
Charles Monia has discussed this with me, and we have agreed that
the definition and specification are correct.  No change will be made. 

13	Port names  (Technical)

Comment:
Section 3.1.14, Change "L_Port" to "NL_Port".  An L_Port refers to
either an NL_Port or an FL_Port in the Fabric topology.

Response:
The definition appears to be consistent with the comment.  No change
will be made.

14	Port names (Technical)

Comment:
General, Change all other references to "L_Port" to "NL_Port"
unless the definition in Comment 13 is intended by the word.

Response:
The definition in 3.1.14 and described in section 4.1 appear to
properly manage the port naming.

15 	FQXID (Technical)

Comment:
Section 3.1.15, In Clause 5.1, para. 1, the Responder X_ID (RX_ID) is
identified as optional.  Therefore, the RX_ID field cannot be
used as a reliable part of the Fully Qualified Exchange ID. 
The Fully Qualified Exchange ID therefore is only a 64 bit
value and is selected by the Initiator when an exchange is
started.

With the addition of permission to use the association header (see
clause 5.5.7) the use of FQXID as a stable reference for a task
identifier (see 3.1.33) is untrue.  A fundamental assumption of SAM
seems to be a single, unchangeable identifier for the life of a
task.  In Fibre Channel, FQXID is not a stable, reliable,
unchangeable entity as described here.  Therefore, it use as the
basis for a task identifier is in doubt.

Response:
After reviewing the cases of interest, it appears that the 
FQXID may actually have several different formats, depending on
what FC-PH functions are used.  The definition will be made
ambiguous to contain all the definitions and the actual formats
will be provided in section 5.1.

The basic formats are:

a)	Simple case

	D_ID/S_ID/OX_ID/RX_ID (where RX_ID is may be "FFFF"X)

b)	Case using Operation Associator and XID invalidation

	D_ID/S_ID/OPA/RPA

16	Information Units

Comment:
3.1.16, Delete "as a single sequence".  See Comment 9.

Response:
This is a paraphrase (naming the FC-4 and naming the FC-2 interface)
of the FC-PH definition in FC-PH Clause 3.1.77.  No change would be
allowed by the definition.

17	Logical Unit Defn (Technical)

Comment:
Section 3.1.17, Device service requests and task management functions
are handled by Logical Units in a target SCSI device.  Both
SAM and FCP need to be updated to reflect this.  SAM
identified these functions as part of the Logical Unit.

Response:
This definition is identical to the definition provided by SAM, revision 12A.
SAM defines the Device Server as a component of the Logical Unit, so the
definition implicitly recognizes the Logical Unit.  SAM defines the
Task Manager as a component of the Target.  The definition is correct
and should not be changed in SAM or FCP.

18	Initiator Identifier (Technical)

Comment:
Section 3.1.18, Delete reference to FC-PH.  This is not a definition
found in FC-PH as the other references to SAM and FC-PH are.

Response:
The reference was intended to indicate where the OX_ID was found.  The
text is corrected to reflect this.

19	Definition reference

Comment:
Section 3.1.22, Add the source of this borrowed definition (FC-PH or FC-AL).

Response:
The reference to FC-AL is made.

20	Port name (Technical)     

Comment:
Section 3.1.23, Add the definition of NL_Port.

Response:
The reference to the FC-PH definition of N_Port is made.

21	Transfer Length (Technical)     

Comment:
Section 3.1.24, The definition in 3.1.7 conflicts with this
definition.  Each command has an explicit or implicit
transfer length.  However, that length is not related to the
number of bytes transferred, except that the total bytes
transferred is greater than or equal to the number implied by
the command.  This is consistent with error recovery
procedures that exists today in SCSI where the target and
logical unit are responsible to see to it that a sufficient
number of bytes are transferred in the correct locations to
provide coverage for the implicit or explicit transfer
length.  However, the total number of bytes transferred by
the target may exceed this explicit or implicit count.  This
problem occurs again in the description of the FCP_DL field
and the calculation of the residual count.  A target must be
allowed, in a standard way to transfer more than FCP_DL bytes
to satisfy its responsibility to manage each command. (See
7.1.4  and 7.4.2.)

Response:
The SAM defines the command byte count as the net number of bytes to
be transferred by the I/O Operation (Revision 12A, section 2.1.1)
The SAM defines the request byte count as the number of bytes to
be transferred by a particular data delivery request.  Overlapped
data delivery requests may occur, moving more data across the
interface than is necessary to satisfy the command byte count.
The definitions are correct and will remain unchanged.  
No change is required in 3.1.24 or 3.1.7.  Comment 143
will address the FCP_DL definitions.

22	Command (Technical)

Comment:
Section 3.1.27, Change "task" to "command".  Each command has a
status.  Completion of task is implied by the status value,
but in FCP, completion is indicated in the choice of
Information Units used by the target when sending status.

Response:
"Task" will be changed to "command".  The second sentence of the
comment is unclear and does not change any other part of the document.

23	FQXID (Technical)     

Comment:
Section 3.1.28, In FCP, the Originator Exchange ID (OX_ID) uniquely
identifies a task from an initiator to a target.  Unlike
SIP/SPI, FCP does not permit a tag value to be reused between
logical units as this definition implies.  An OX_ID used for
any task to any logical unit from an initiator to the same
target cannot be reused for any other logical unit until the
task for the original logical unit completes.  Therefore, FCP
limits the total number of tasks in a single target through
one port to 65535 from the same initiator, not 65535 per
logical unit as this definition states.

Response:
The definition will be modified to reflect this characteristic.
"tag:  an identifier to uniquely identify tasks when more than
one task has been requested by a given initiator for a given
logical unit.  [SAM]  FCP uses the unique value of the Originator X_ID, 
defined in FC-PH, as a unique identifier for each task provided to any 
logical unit in the target."

24	Command (Technical)     

Comment:
Section 3.1.29, Change "commands" to "tasks" or "I/O operations".

Response:
The definition of target will be changed to conform to SAM:
"target: an SCSI device which receives SCSI commands and directs
such commands to one or more logical units for execution."

25	Identifier Reference

Comment:
Section 3.1.30, Delete the reference to FC-PH.  The choice of
identifier is made by FCP and has nothing to do with FC-PH.

Response:
The reference is corrected to indicate where the definition of
the Destination_ID and Exchange Originator is found.

26	FQXID and RX_ID

Comment:
Section 3.1.33, FQXID, as defined in 3.1.15 does not require RX_ID. 
The Source ID, Destination ID and OX_ID are sufficient to
uniquely identify a task.  The RX_ID field is optional and
should be dropped from the definition of both FQXID and task
identifier.

See comment 15.  The FQXID value is not a stable reliable
identifier in FC-PH that can be used as an unchanging task
identifier for the life of a task.  The Fibre Channel Association
header and the process of exchange ID reassignment can cause
changes to the OX_ID, RX_ID, S_ID and D_ID fields during the life
of an exchange.

Response:
The corrected definition of FQXID in 3.1.15 and the text to be added
to section 5.1 will allow the task identifier definition to be used
unchanged.

27	Editorial convention

Comment:
Section 3.3, Add a paragraph similar to the one below.

"In case of a conflict between text, tables and figures, the order
of precedence for resolving a conflict is text, tables, and lastly,
figures."

Response:
The following text from FC-PH will be added to section 3.3.

"In case of any conflict between figure, table, and text, the text
takes precedence.  Exceptions to this convention are indicated in the
appropriate sections."

28	Topology definitions

Comment:
Clause 4.1.  The point-to-point topology, the Fabric topology
and the Arbitrated Loop topology each provide a service to
N_Ports or NL_Ports.  FC-PH is a common transport service
that operates with any of these topologies.  Delete paragraph
2 or reword it.  Each SCSI device must choose from one of the
three topologies to connect with another SCSI device when
using FCP.

IF there is to be a topology discussion, it is best delegated to
an annex if it is needed at all in FCP.

Response:
The reviewers of Revision 7 of the FCP requested that FC-AL
be explicitly included in the document.  The first paragraph will
include a reference to a switching fabric.

29	Layer definition (Technical)

Comment:
Clause 4.1, para. 3.  A ULP uses the services of an FC-4, not
FC-PH.  FC-4s use the services of FC-PH.  FCP is to be
described in terms of Exchanges and Information Units (not
sequences).  Change "L_Ports" to "NL_Ports".  In line 4,
change "will be" to "are".

Response:
a)	Accepted.  Also effects Foreword, 3.1.12, 3.2, 4.2, 6, 6.1,
	7.4.5
b)	L_Port will be changed to NL_Port where appropriate.
c)	"are" is accepted.


30	Layer definition (Technical)

Comment:
Clause 4.1, para. 4.  Fibre Channel ports are assumed to have
a common service interface for use by FC-4s (not ULPs) (line 2).  
An example of the interface from a SCSI initiator ULP is
specified in CAM.  There is no equivalent for the target ULP.

Response:
Accepted,  See comment 29.
            

31	Inclusion of frame info.

Comment:
Clause 4.1, para. 6, top of page 6.  Delete "and frame
structures".  Fibre Channel FC-4s are not to deal with
frames, only information units.  The term frame should not
appear in any FC-4.  Each action between Initiator and Target
needs to be defined as an Information Unit.

Response:
Accepted for Clause 4.1, 4.5.

32	Information Unit

Comment:
Table 1, line 3, Change "sequence" to "Information Unit".

Response:
The table is drawing the analogy between SCSI Request/Response
Primitives and the comparable FC-PH primitive.  The comparable
FC-PH primitive (not the information payload) is the sequence.
No change will be made.

33. 	Resource limitations (Technical)

Comment:
Clause 4.1, para. 7 (after Table 1).  In SCSI, today, the
number of concurrent tasks has been limited by initiator and
logical unit implementations, not the port implementations. 
FCP limits  the level of concurrent tasks to attributes of
the port implementations and not the Initiator or Logical
Unit.  That is, the two ports used between an initiator and
target may limit the task concurrency to a level below that
of the initiator and logical unit implementations.  A
physical port change, rather than a possible firmware change,
maybe required to increase the amount of concurrency.  This
is not consistent with other SCSI mappings.  This limitation
must be clearly stated since it is contrary to current
practice and other SCSI-3 protocols.

Response:
In SCSI, today,  the number of concurrent tasks has been limited
by initiator and logical unit implementations.  These are
the ports for SCSI today and those limitations are port
limitations.  In any SCSI mapping, those limitations may be
formulated by the architecture, by the port hardware, or by
the port firmware.  For targets implementing multiple logical
units, the limitation may exist at the logical unit level or
at the target level.  There is nothing unique to FCP in this
respect.

To more clearly define to this characteristic, the
sentence will be changed to read:
"The number of Exchanges that may simultaneously be open between
an initiator FCP_Port and a target FCP_Port is defined by the
FC-PH implementation.  The architectural limit for this value
is 65535. The maximum number of active Sequences that can
simultaneously be open between an initiator FCP_Port and a target FCP_Port is
defined by the FC-PH Sequence_ID as 256.  To allow task management
exchanges to be originated, a certain number of extra Exchange IDs and 
at least one extra Sequence ID should always be available."

34	Informative section

Comment:
Clause 4.2.  This clause needs to be marked as "Informative".

Response:
The clause is tutorial, but has normative sections.  No change is 
required.


35	FCP I/O Operation

Comment:
Clause 4.2, paras 1, 2, The term FCP I/O Operation includes
more than just commands or lists of commands.  Only the term
"task" is appropriate here.

Response:
The term "task" refers only to the work created in a logical
unit associated with a command or group of linked commands.
The correct term for this is FCP I/O Operation.  No change is required.

36	Editorial 4.2

Comment:
Clause 4.2, para. 2, Lines 1-2, Change "unsolicited command"
to "Unsolicited Command" (See Table 1.  See earlier
discussion of using FQXID as the task identifier.  The RX_ID
field is optional and is not available to the initiator until
AFTER the first command of each task is sent to the target. 
Then X_ID reassignment may change the values of the FQXID
over time.

Response:
a)	Capitalize "unsolicited command".
b)	Redefinition of FQXID resolves the remainder of the comment.

37	Information Units

Comment:
Clause 4.2, para 2, line 6, Change "transfers" to "IUs".

Response:
Accepted.

38	Editorial 4.2

Comment:
Clause 4.2, para. 3, line 3, Change "described" to
"describes".

Response:
Accepted.

39	Editorial 4.2

Comment:
Clause 4.2, para. 3, line 4, Change "solicited data sequence
" to "Solicited Data IU".

Response:
Accepted.

40	Editorial 4.2

Comment:
Clause 4.2, para. 3, line 5, Change "information" to
"payload".

Response:
Accepted.

41	Editorial 4.2

Comment:
Clause 4.2, para. 3, line 6, Change "described" to
"describes".

Response:
Accepted.

42	Editorial 4.2

Comment:
Clause 4.2, para. 3, line 6, Change "solicited data sequence"
to "Solicited Data IU".

Response:
Accepted.

43	Editorial 4.2

Comment:
Clause 4.2, para. 3, line 7, Change "information" to
"payload".

Response:
Accepted.

44	Editorial 4.2

Comment:
Clause 4.2, para. 3, lines 7-8, Change "Data delivery
request" to "Data Delivery Requests".  (See Table 1).

Response:
Accepted.

45	Editorial 4.2

Comment:
Clause 4.2, para. 4, line 1, Change "transferred" to
"transferred (if any)".

Response:
A modification to line 1 of paragraph 3 is preferred:
"When the device server for the command has completed the 
interpretation of the command, has determined that data transfer
is required, and is prepared...."

46	Editorial 4.2

Comment:
Clause 4.2, para. 4, line 1, Change "command service request"
to "Command Service Request".

Response:
Accepted.

47	Editorial 4.2

Comment:
Clause 4.2, para. 4, lines 2-3, Change "Status Byte" to
"Status".

Response:
Accepted.

48	Editorial 4.2

Comment:
Clause 4.2, para. 4, line 4, Change "command status response
is the last sequence of the Exchange and terminates the FCP
I/O Operation" to "Command Status IU terminates the command. 
The choice of Information Unit type determines whether the
task ends or continues to another command."

Response:
The last sentence will be changed to:
"The Command Status IU terminates the command.  The SCSI logical unit
determines whether additional commands will be performed in the
FCP I/O Operation.  If this is the last or only command
executed in the FCP I/O Operation, the FCP I/O Operation and the
Exchange are terminated."

49	Editorial 4.2

Comment:
Clause 4.2, para. 5, Page 7, Change "FCP I/O Operation" to
"command".

Response:
Accepted.

50	Editorial 4.2

Comment:
Clause 4.2, para. 6, line 2, Change "FCP I/O Operation." to
"task.  The choice of IU from the target determines whether
the task continues."

Response:
The paragraph will be rewritten to say:
"If the command is linked to another command, the FCP_RSP payload
shall contain the proper Status indicating that another command will
be executed.  The target shall present the FCP_RSP in an IU that
allows command linking.  The initiator shall continue the same
Exchange with an FCP_CMND IU, beginning the next SCSI command.
All SCSI commands linked in the FCP I/O Operation except the last
are executed in the manner described above."  	

51	Concurrency limits (Technical)

Comment:
Clause 4.2, para. 7.  This concept of task concurrency
limited by the choice of the port you buy for FCP must be
clearly stated.  Those not familiar to the concepts for
identifying tasks for FCP may not recognize that, unlike SCSI
SBP, the queue depth is determined by hardware and not
software.  If this method of limiting concurrency is
acceptable to the X3T10 committee, FCP must clearly state it
as a limitation and warning to potential users of FCP.

Response:
As pointed out in Comment 33, this concept is well understood
and is typical of all SCSI environments.  In particular, SBP
has an architecturally limited number of nodes and a hardware
and software resource limited number of simultaneously active
transactions, depending on the "port" you buy.  
Comment 33 resolves this problem.  This paragraph will be modified
to say:
"The number of FCP I/O Operations that may be active at one time
depends on the queueing capabilities of the particular SCSI devices
and the number of concurrent Exchanges supported by the FCP_Ports."

52	Editorial 4.2

Comment:
Clause 4.2, para. 8, line 2, Change "sequences of FCP I/O
Operations" to "IUs of FCP".

Response:
Resolved by Comment 10.

53	Class 3 definition (Technical)

Comment:
Clause 4.2, para. 8, line 3. If "interlocked IU transmission"
is part of FCP then it must be described here to permit Class 3.  
However, the proposal to use FCP in Class 3 on the
arbitrated loop does not require interlocked IU transmission. 
Therefore, this requirement must be removed.

Response:
The referenced sentence will be changed to read:
"Class 3 service may be used.  The error recovery characteristics
of Class 3 may require that it be allowed only in certain operating 
environments to meet reliability and error detection requirements."

54	Concurrency limits (Technical)

Comment:
Clause 4.3, Page 7, para.2, line 3, Change "sequence" to "IU".

Unlike SIP/SPI, the limitations of a Fibre Channel port to start
a new exchange may limit the ability of an initiator to perform
task management functions in a timely manner.  For example, if the
limit of the number of concurrent exchanges is reached between an
initiator and a target (across all logical units), the initiator
is unable to start a new exchange to perform task management
functions.  This is a potentially serious limitation since each
initiator must not attempt to use the last exchange it has
available with each of N targets to be able to start the
appropriate task management functions when required to each target. 
This operational limitation does not exist in the other protocols. 
If this behavior is acceptable to the X3T10 committee, this
limitation must be placed in the standard as a warning to
implementors.  This limitation is not obvious to those who have a
casual acquaintance with Fibre Channel and may cause serious
implementation or operational difficulty if not fully understood
and plainly stated in the FCP standard. 

This problem of allocation of concurrent open exchange resources
in a port also requires low level resource allocation in the
initiators and targets that is not currently required in the other
SCSI mappings. 

Response:
a)	See Comment 10.
b)	See Comment 33.  Note that the architectural limitation only exists 
between D_ID/S_ID pairs and not among multiple targets, simplifying
any required management functions.  No change is required in this section.

55	Editorial 4.3

Comment:
Clause 4.3, para. 2, line 3, Change "CDB of" to "FCP_CDB
field in".

Response:
Accepted.

56	Editorial 4.3

Comment:
Clause 4.3, Table 2, line 2, column 2, Change "Login/Logout"
to "Process Login/Logout".  Login and Logout (without the
"process" adjective) has an entirely different meaning in
Fibre Channel.

Response:
To correctly define all the parameters that control the operation
of an FCP device, the implicit or explicit login parameters for
N_Port Login/Logout, Fabric Login/Logout, and Process Login/Logout
must all be known.

The line will be removed from the table, since PRLI/PRLO are
contained in section 4.4.

Section 4.5 will be expanded to say:

"FC-PH allows management protocols above the FC-PH interface to 
perform link data functions.  The standard FC-PH Primitive Sequences,
link management protocols, and Basic and 
Extended Link Services are used as required by FCP devices.
Implicit login functions are allowed."


57	Mandatory/Optional (Technical)

Comment:
Clause 4.3, Table 2, lines 2, 7, and 8.  These functions
should be  mandatory in the FC-4.  The capability to perform
these actions is dependent on the SCSI ULP, especially the
last two.  They are discoverable attributes managed by the
Inquiry data and the ACA field of the CDB.  The FC be able 
to manage these functions when the Initiator and
logical units  agree to use the functions.  This it the first
of several instances where the FC-4 appears to be arbitrarily
limited when interoperability from some profile is a logical
constraint.  The FCP-FC-4 must support the functions. 
Whether they are invoked or not is up to the ULPs and not of
concern to the FCP FC-4 or the ports.  As a general rule, any
functions that are logically managed SHALL be supported by
the FC-4.  Otherwise, a SCSI device may implement a function
which cannot be performed because of the choice of FC-4 or
port manufacturer.

Response:
After considerable discussion, the SAM document has been
modified to indicate clearly which functions are mandatory 
for all protocols; which functions are mandatory for a
protocol to define but optional for a SAM compliant device
to implement; and which functions are optional for both
a SAM compliant protocol and a SAM compliant device implementation.
It is the intent of FCP to define how these functions are
implemented, but allow them to be optional for compliance
with FCP.  This also serves as a warning to software
designers that compliant ports are allowed to not implement
certain functions.  Software designers should use alternate
mandatory mechanisms for generic drivers.  No change is
required in these lines.


58	Mandatory/Optional (Technical)     

Comment:
Clause 4.4 and Table 2.  The FC-4 must support this function
if called upon to perform it.  The ULP is not obliged to
support it.  That is, implicit process login is a function of
the ULPs and not of either the FC-4 or the FCP_Ports.

Response:
The FCP document defines the mechanisms for implementing PRLI/PRLO.
Compliant devices may choose to use an implicit login process
and reject explicit PRLI operations.  The first sentence of the text 
is modified to read:
"The Process Login/Logout Extended Link Service is optionally used to 
establish the operating relationships between two FCP_Ports.  Implicit
Process Login/Logout parameters may be defined for FCP_Ports."

59	PRLI Image (Technical)

Comment:
Clause 4.4, para. 1, line 3, the concept of "multiple images"
has been added and appears to violate the definition of
unique initiator or target identification based on the S_ID
or D_ID field values as specified elsewhere in FCP.  Since it
appears that adopting the FC-SB Process Login/Logout protocol
introduces the concept of multiple images, the ULPs cannot
depend on the S_ID field to unequivocally identify the
initiator or the target.  The process associator permitted
with this type of process login and the rules for use in FC-
PH adds a new identifier potentially for either the initiator
or target or both which is NOT an alias of the S_ID or D_ID
values.  The S_ID and D_ID identify generally which
initiators or target images are involved, but not exactly. 
An optional header is required to uniquely identify the
initiator or target.  This is contrary to other parts of FCP.

Response:
The FQXID definition is modified in section 5.1 to include
Process Associator information, which allows multiple images.
No change is required in section 4.4.  See Comment 15.

60	Clarify sequences

Comment:
Clause 4.5, para. 1, line 2.  Primitive Sequences (notice
capitalization from FC-PH), are not associated with either
basic or extended link services.  Reword the second sentence
to correct this implication.  Change "frames" to "Sequences". 
All basic and extended link services are a implemented as an
exchange of Sequences. 

Response:
See comment 56, which rewrites this clause.

61	Editorial 5.1

Comment:
Clause 5.1, page 9, para. 1, line 1, Change "fibre channel"
to "Fibre Channel".

Response:
Accepted.

62	FQXID clarification (Technical)

Comment:
Clause 5.1, para. 1, line 2.  After Process Login with
process associators required, the FQXID no longer identifies
either the initiator or the target or both.  Identification
depends on the contents of the optional header called the
Association Header.  This paragraph and the concepts of
initiator and target identification in FCP require rethinking
and reworking before it we have a workable set of definitions
and unequivocal identification of initiators and targets.

Response:
Clause 5.1, first paragraph, is rewritten as follows:

"Addressability to each Fibre Channel FCP_Port is defined by the
Source and Destination FCP_Port address identifiers.  Identification
of FCP I/O Operations on the Fibre Channel is achieved by using the
Fully Qualified Exchange Identifier (FQXID).  The FQXID is defined
in the following table.  The method used to identify FCP I/O 
Operations internal to the application client and the device server
is not defined by this standard.

	Table defining Fully Qualified Exchange Identifier (FQXID)

Condition                      D_ID  S_ID  OX_ID  RX_ID  OOA    ROA

Basic Operation                  R     R     R      
 Identified by initiator

Basic Operation                  R     R     R      R
 Identifed by target

X_ID Invalidation Operation      R     R                  R    
 Identified by initiator

X_ID Invalidation Operation      R     R                  R     R
 Identified by target


The target is required to be cognizant of the OX_ID to perform
error recovery and task management functions."

63	Editorial 5.1

Comment:
Clause 5.1, para. 2, line 1, Delete "SCSI Devices and".  

Response:
Accepted.

64	FQXID clarification (Technical)

Comment:
The FQXID is not a stable value when X_ID reassignment is
active by either SCSI Device.  A new handle to provide
unequivocal identification is required.

Response:
See Comment 62

65	Mandatory/Optional (Technical)

Comment:
Table 3, page 10, Row T3, Change the M/O column value to M. 
The FC-4 must be capable of supporting the processes of the
Initiator and Logical Units.  

Response:
Command linking is a SAM option that is defined by FCP for compliance.
Implementations are not required to support command linking for
compliance with FCP. 

66	Clarify action

Comment:
Table 3, page 10, Row T5.  There must be a set of values
chosen for this action.  In Fibre Channel, either Sequence
Initiative (SI) is transferred or it is not.  The standard
cannot be ambivalent.  Fill in the value needed to correctly
cause the processing intended.

Response:
The X value for Task Management functions will be changed to
"hold".

67 	Change reference (Technical)

Comment:
Table 3, page 10, Note 4, Change T10 to T11.

Response:
Accepted.

68	SI definition (Technical)

Comment:
Table 4, page 11, Rows I4 and I6, Change the SI values to
acceptable values.  Even though these are the last
information units of an I/O process, valid sequence
initiative values are required by Fibre Channel to be placed
in the header fields.

Response:
Sequence Initiative will be transferred to simplify FCP_RSP generation.

69	Mandatory/Optional (Technical)

Comment:
Table 4, page 11, Row I5, Change the M/O column value to M. 
The FC-4 must be capable of supporting the processes of the
Initiator and Logical Units.

Response:
Command linking is a SAM option that is defined by FCP for compliance.
Implementations are not required to support command linking for
compliance with FCP. 

70	Move examples

Comment:
Clause 5.3.  Move this entire clause to Annex A.  It is purely
exemplary material.

Response:
Accepted.

71	Editorial, Tables 5-13

Comment:
Tables 5 - 13, Change "UI" to "IU".

Response:
Accepted.

72	Normative (Technical)

Comment:
5.3, para. 1, line 3, Move the sentence beginning "Sequence
streaming...." to clause 5.2.  This is an allowable option
for an implementation and needs to be removed from these
examples.

Response:
This case is already covered by Note 4 in Table 3 and Note 3 in Table 4.
No change is required.

73	Editorial, 5.3

Comment:
Clause 5.3, para. 1, line 4, Delete the last sentence.

Response:
Accepted.

74	Clarify Abort Task (Technical)

Comment:
Clause 5.3.9, the Abort task function cannot be accomplished using
any IU defined in the standard.  An example of how it is
proposed to be handled needs to be given.  The ULP is not
aware, or should not be aware that Fibre Channel is being
used.  Therefore, an FC-PH link level request is beyond its
power to request.  Explain the sequence of events that causes
this action to be taken.

Response:
The ULP is not aware that Fibre Channel is being used.  The
mapping level FC-4 is certainly aware and uses link services made
available to it through the FC-PH service interface as described
in examples in Annex S, Clause S.3.  The ABORT TASK task management
function is performed using the mechanism described in section 
7.1.2, page 25.

75	Class 3 (Technical)

Comment:
Clause 5.4, para. 1, line 8, The concept of "interlocked IU
transmission" is not defined.  This concept must be defined
since there is a proposal to operate FCP using class 3.  This
process is a required operational procedure that must appear
in FCP.

Response:
This was previously addressed by Comment 53 applying to Clause 4.2.
The sentence should be removed from 5.4.

76	FQXID Clarification (Technical)

Comment:
Clause 5.5.2 and 5.5.3, The FQXID is improperly defined when the FC-
4 login indicated that process associators are to be used. 
The D_ID and S_ID fields do not correctly define the
initiator or target in this case.  Since the FC-4 login is
required, the proper identifiers must be made clear in all
circumstances and not left out of the standard.  When process
associators are being used, the S_ID and D_ID values may
change over the course of a task and still the integrity of
the task between an initiator and a logical unit is correctly
maintained.  I realize that in one of the industry group
profiles that process associators are not permitted, but this
is the FCP standard and not that profile.  The standard must
reflect the true power and flexibility permitted by the tools
in FC-PH.  The FC-4 login/logout process adds a new dimension
to naming initiators and targets.  The name is loosely
coupled to a SET OF PORTS and not to a single port as occurs
in SIP/SPI.  Refer to Annex R in FC-PH for managing exchanges
with association headers.  This area is not complete in FCP.

Response:
The Process Associator is not the identifier of the 
Exchange during XID Invalidation.  The Operation Associator is
the required parameter and is not part of the PRLI definition.
The expansion of the FQXID definition in comments 5 and 62 will resolve
this problem.  No change is required in 5.5.2 or 5.5.3 to be
compliant with the change.

77	OX_ID values (Technical)

Comment:
Clause 5,5,9, para. 1, line 2.  This restriction on not being
allowed to use an OX_ID of 'FFFF'h.  FC-PH permits this value
which allows only one exchange between a port pair.  This is
very similar to the "untagged I/O process mode" in SCSI-2 and
untagged tasks in SAM.  This value should be allowed.  A note
about the effect might be appropriate, but the value should
not be prohibited.  In simple systems only one resource may
be all that is needed and FC-PH permits such a simple
implementation.  FCP is not reduced in any way or otherwise
incorrect if this value is permitted.

Response:
FC-PH Revision 18.9 indictes that if OX_ID is allowed to
be hexadecimal `FFFF' for all exchanges, that the originator
is using an alternate sequence tracking mechanism.  At present,
no such mechanism is defined for FCP and the requirement for
a separate exchange for some task management functions requires
that more than one exchange per S_ID/D_ID pair be allowed.  As
a result, it is appropriate for the FC-4 to prohibit the use
of an OX_ID of `FFFF'.  No change is required.

78	Clarify base addresses

Comment:
Clause 5.5.11, para. 1, First, both the initiator and target have
base addresses.  This is not exclusively a property of an
initiator.  Second, the base address inside either SCSI
device is never exchanged with the other in FCP so a long
discussion is of little value. Relative offset requires more
work since the casual reader may have no idea about the
management of relative offset in FC-PH.  Therefore a
discussion is warranted and the rules should be very clear. 
Relating the relative offset use to IUs by name is a way to
simplify this problem.

Response:
The target does not define a base address for data transfers in 
SAM.  The SAM uses words that mean "base address", specifically
"start of the buffer" and applies them only to buffers in the
application client.  It is the responsibility of the SCSI
target to understand the meaning of each segment of data in
the context of the particular command being executed.
The definition of Base Address is taken from FC-PH, section
18.11, which indicates that it is the responsibility of the ULP/FC-4
to define the meaning.
The concept is clearly defined in 3.1.5.
The IUs that use the Solicited Data Category will be listed in the
text.

79	Clarify base addresses (Technical)

Comment:
Clause 5.5.11, Para. 1, lines 4-5.  The base address does not refer
to the first byte of any IU.  In category 5, there is a
header of 12 bytes in front of the data bytes of interest to
the SCSI device.  This error must be corrected.  

Response:
Section 18.2, tables 30-32 of FC-PH indicate that the original
text of 5.5.11 is correct.  No change is required.

80	Optional function (Technical)

Comment:
Clause 5.5.11, para. 1, lines 5-6.  An option is given without a
definition of the means to decide when and if it can be used
by an initiator and a target.  This means must be specified.

Response:
FC-PH indicates that F_CTL bit 3, together with the LOGI service
parameters is used to indicate whether or not an RO is required
and present.  It does not appear necessary to duplicate this
clause (18.11) of FC-PH in the the FCP document.  No change is
required.

81	Editorial, 6

Comment:
Clause 6, para 2, line 5, Change "acceptance" to "acceptance or
rejection".  On the same line, change "acceptance or
rejection to" to "response to".

Response:
Accepted.

82	PRLI Clarification (Technical)

Comment:
Clause 6.1, para. 1, line 2, The concept of "process images" is
unknown in SCSI and requires development and explanation on
its function and use in SCSI-3 since the text permits use of
this function of FC-PH by initiators and targets.  A
reference to FC-SB is insufficient.  Paragraph 2 also has
text about multiple images that must be corrected, if
required.  The SCSI-3 actions specified for receipt of a PRLI
seem to indicate that only one at a time is valid.  Is
something missing?

Response:
The following text will be added to indicate the effect of
creating image pairs and assigning them properties.  The
text is added as a new paragraph after paragraph 2.

"The effect of the creation of image pairs is to create
one or more virtual initiators or virtual targets behind each
FCP_Port.  As an example, an FCP_Port can identify itself to another
FCP_Port as having one or more logically separate SCSI FCP initiators,  
one or more logically separate SCSI FCP targets, and a number of logically
separated processes performing other FC-4 mappings.  The FCP_Port
receiving the PRLI can reject it, indicating that it cannot support
the required functions, or accept it."


CONTACT FC-SB EDITOR FOR CLARIFICATION OF PRLI PROTOCOL.  

83	PRLI Clarification

Comment:
Clause 6.1, para. 1, line 3, last sentence.  It is not obvious that
Table 14 permits more than one process associator in each
direction.  Please explain the mechanism or delete the
sentence or indicate that the login may be used more than one
time, if that is the case.

Response:

84	PRLI Clarification (Technical)

Comment:
Clause 6.1, Since the PRLI is like an IU, it must be described as
such with all of the values for the header fields clearly
stated in the standard.  The accept is not a normal frame so
that must be explained and the frame header contents also
specified.

Response:

85	Error presentation (Technical)

Comment:
Clause 6.1, para. 5, The contents of the SENSE KEY and ASC and ASCQ
fields are not specified.  If existing values are to be used,
they must be specified.  If new values are required, a
proposal must accompany specification of this behavior
specifically for the FCP standard.

Response:

86	Unit Attention (Technical)

Comment:
Clause 6.1, para. 5, line 2, the Unit Attention is "reported" not
transmitted.  Since asynchronous event reporting is optional,
the Unit Attention must be queued until the initiator starts
a task, and then only reported for certain commands.

Response:

87	PRLI Clarification (Technical)

Comment:
When a new initiator logs in with a target, it should not
cause the equivalent of a Target Reset, which is the reaction
specified.  There seems to be no need to report that a new
initiator has logged in with a target.  There is no such
behavior in SCSI-2 or in any of the other protocols.  This
specification seems to create an undue instability in the
system.  Note also that since targets can login to
initiators, an intermittent use device, like a scanner, can
totally destroy a system environment by the simple act of
logging in.  This action must be altered to not be so
disruptive.  

Also, since the login procedure is symmetrical, what is the
reaction of an initiator that is logged in to by a target.  That
is, if the target sends the PRLI, is the initiator reset.  I
believe that it must be to be consistent with the behavior required
of targets when they receive a login.

Response:

88	Editorial, 6.1

Comment:
Clause 6.1, para. 5, line 3, Change "sate" to "state".

Response:

89	PRLI Clarification (Technical)

Comment:
Clause 6.1, para. 5, line 3, Reword the sentence beginning "No
tasks...." to state that all tasks shall be aborted, no
status is returned for any task, and all reservations are
released by the affected SCSI device.  See comment 87 for
symmetrical behavior requirements in this area for
initiators.

Response:

90	PRLI Clarification (Technical)

Comment:
Clause 6.1, para. 6.  Every device must have some default PRLI
payload values.  What is does not know is the default of the
other SCSI devices with which it communicates.  Storing
information by S_ID or D_ID is not acceptable.  The Fabric or
arbitrated loop may cause the physical addresses of the ports
to be reassigned.

Therefore, it seems that PRLI is explicitly required between any
two SCSI devices before they can communicate using I/O Operations. 
That is, one device may have its defaults set to Command/Data Mixed
Allowed and the other one have that attribute prohibited.  These
two SCSI devices will not communicate effectively.

Response:

91	PRLI Clarification (Technical)

Comment:
General, As noted in the comment 90 above, since the S_ID is
probably more unstable a value than a SPI SCSI device
address, how is MODE/SELECT-SENSE parameter saving managed
with FCP?  

Response:

92	PRLI Clarification (Technical)

Comment:
Clause 6.1, para. 7, Receipt of a new PRLI is not so much a request
to modify as it is to perform an implicit logout and a new
login.  It should be stated as such and the rules for
behavior then restated in this light.

Response:

93	Editorial 6.1.1

Comment:
Clause 6.1.1, Word 0, Bits 3-24, para. 1, line 1, Change "16-byte
set" to "PRLI".

Response:

94	Correct typo, 6.1.1 (Technical)

Comment:
Clause 6.1.1, Word 0, Bit 15, paras. 1-2, Change "word 2" to "word 1".

Response:

95	Correct typo, 6.1.1 (Technical)

Comment:
Clause 6.1.1, Word 0, Bit 14, paras. 1-2, Change "word 3" to "word 2".

Response:

96	Correct typo, 6.1.1 (Technical)

Comment:
Clause 6.1.1, Word 3, Bit 4, para 1, line 2, Change "2 and 3" 
to "5 and 4".

Response:

97	Include Reject to PRLI (Technical)

Comment:
Clause 6.1.1, Word 3, Bit 4, para. 1, top of page 20, Define a
response of FCP_RJT.

Response:

98	Editorial 6.1.1

Comment:
Clause 6.1.1, Word 3, Bit 3, para. 1, line 2, Change "data are" to
"data shall be".

Response:

99	PRLI Clarification

Comment:
Clause 6.1.1, Word 3, Bit 3, para. 1, last sentence, The only time
these parameters are exchanges is during a PRLI exchange. 
This sentence does not make sense.  Perhaps it should be
deleted.

Response:

100	Transfer disabled (Technical)

Comment:
Clause 6.1.1, Word 3, Bit 3, para. 2, The relationship between Word
3, Bit 3 and Word 3, Bit 0 must be stated in a table.  There
are at least two valid combinations acceptable.  Paragraph 2
states one rule,  The term "write operation" is undefined.

Response:

101	Editorial 6.1.1

Comment:
Clause 6.1.1, Word 3, Bit 2, para. 1, line 2, Change "data are" to
"data shall be".

Response:

102	PRLI Clarification

Comment:
Clause 6.1.1, Word 3, Bit 2, para. 1, last sentence, The only time
these parameters are exchanges is during a PRLI exchange. 
This sentence does not make sense.  Perhaps it should be
deleted.

Response:

103	Transfer disabled (Technical)

Comment:
Clause 6.1.1, Word 3, Bit 2, para. 1, The relationship between Word
3, Bit 2 and Word 3, Bit 1 must be stated in a table.  There
are at least two valid combinations acceptable.  The term
"read operation" is undefined..

Response:

104	Clarify error sequences (Technical)

Comment:
Clause 6.1.1, Word 2, Bit 2, para. 1, There seems to be no rationale
for unconditionally using I6 or I7 as the only response when
data and response may be combined in one IU.  A check
condition between bursts can cause the last response for a
command to be I4 which violates the "shall" in this
paragraph.  Also, a Terminate Task message can cause the same
behavior.  Therefore, a  target is granted PERMISSION to use
IUs I6 and I7, but it shall not be required to use them as
the only means of response.  

Response:

105	Clarify PLRO

Comment:
Clause 6.2, para. 1, line 2, Change "pairs" to "pair.  No case for
sending multiple pairs has been established.

Response:

106	Clarify PLRO (Technical)

Comment:
Clause 6.2, para. 1, Since either SCSI device may logout, the
behavior for initiators receiving the logout must be
specified.  It appears that both devices are forced into
reset when either logs out or logs in.  This is extreme
behavior and probably should be rewritten.  The dynamic
behavior of systems means that a lot of disruption occurs for
no valid reason.  Such behavior has not been part of SCSI in
the past and it does not appear in other protocols.  Perhaps
it is overkill here, too. 

Response:

107	Editorial, 6.2.1

Comment:
Clause 6.2.1, Word 0, Bits 31-24, Change "16 byte set" to "PRLO".

Response:

108	Correct typo, 6.2.1 (Technical)

Comment:
Clause 6.2.1, Word 0, correct all word references for words 1 and 2.

Response:

109	Clarify Category 6

Comment:
Clause 7.1, It should be clearly stated that the first 8 bytes of
the FCP_CMND IU are controlled by FC-PH and not subject to
change.  This is a side effect of using category 6.

Response:
In section 7.1.1, the first paragraph will have a second sentence
added indicating:
"The FCP_LUN field is specified by FC-PH for all IUs of Category 6."

110	Address model (Technical)

Comment:
Clause 7.1.1, para. 2, line 3, Change "device at the FCP_Port" to
"Logical Unit".  SAM has no assumption that one logical unit
in a target has any cognizance of or information about the
next Logical Unit if any.  The behavior identified in this
paragraph is contrary to both SAM and historical SCSI target
operation.  Therefore, one Logical Unit is to be considered
totally independent from the next.  The only thing in common
may be sharing a common access port to the service delivery
subsystem.  Therefore, no hint about internal address
structure or other information can be guaranteed to be
available from or desirable from Logical Unit 0.

The wording in this paragraph has not been accepted by the X3T10
as acceptable standard behavior.  We deleted the concept of a
target routine which is a more likely spot to find such information
since it must route information to the Logical Units, but that
still means that the Logical Units are independent.  I realize that
the 64-bit address space used with FCP is too large to poll, but
Logical Unit 0 has been allowed to be and should remain an
independent entity as it historically has been.

Find some other mechanism for determining the Logical Units that
exist in a Target than the one specified here.  Also, this text
seems to assume a homogeneous set of Logical Units per target -
that too is not an acceptable assumption.

Is the address structure in Annex B the one accepted by X3T10 for
SCC model devices?   Since the project is just in the approval
process, this assumption in FCP seems to be in error.  If it were
worded as one way to approach the problem that might be
instructive, but I don't think it is necessarily THE way.

Response:
The text will be modified to indicate that other logical units can
be identified only for those SCSI device models that define an
address structure.
The last sentence will be changed to read:
"An example of a four-layer hierarchical address structure suitable
for use by a SCSI RAID device model is given in Annex B."

111	Clarify 7.1.1 (Technical)

Comment:
Clause 7.1.1, para. 2, line 1, Change "command" to "I/O operation". 
Delete the second sentence.  In the INQUIRY command, if the
command is sent to an invalid logical unit, a response is
generated.  There has been no proposal to change that 
behavior in SPC.  Therefore, some commands may respond with
invalid logical unit selection, but at least one command has
an alternative behavior.  If the behavior as stated is
accepted, all targets on all protocols require the same
response and some of the values in the Qualifier field, or
the entire Qualifier field may be eliminated from the INQUIRY
response.   With the behavior specified, no information about
potential logical units is available.

Response:
a)	Command is the proper word in this context.
b)	The second sentence is modifed according to Comment 110.
c)	SAM requires that LUN 0 exist.
No change is required by this comment.

112	Change Abort Task (Technical)

Comment:
Clause 7.1.2, Table 17.  If the terminate task function can be
accomplished by an IU, then the Abort Task function can also
be accomplished by an IU.  If this is not true, then the
Terminate Task function must follow the model of the Abort
Task function.  The constraints on access to the logical unit
are the same when either task management function is
required.  They should be handled in a similar fashion.  The
single exception for handling the Abort Task function is
curious.   If sequence initiative is not available, as it may
not be in either case, use the request sequence initiative
protocol and then send a common IU.  Define Byte 2, bits 4,
3, or 0 as the Abort Task function.  See the definition of
Terminate Task on page 24.  Abort Task should behave in a
similar consistent fashion.

Response:
Terminate Task and Abort Task are two quite different functions.

The only promise of Terminate Task is that the device will try
to terminate an operation early if possible.  The task must be
terminated normally in every respect except possibly for a
reduced amount of data transferred.  The Terminate Task can be
ignored at every state of its execution.  Because of these
characteristics, Terminate Task must be offered to the
target in a manner that will not disrupt the devices ability
to properly complete the command.

The promise of Abort Task is that, when performed, the device will
immediately stop all efforts to complete the operation.  No 
notification about the completion state of the task is required.
Abort Task need not be concerned
about disrupting the device and should have a high probability
of correct delivery, even when the FCP protocol would not normally
allow its transmission.  The Recovery Abort protocol meets these
requirements.  

Recovery Abort should probably be defined separately for use
by the Abort Task task management function.  See comment 117.

113	Correct CLEAR ACA (Technical)

Comment:
Clause 7.1.2, page 24, CLEAR ACA, Delete the last two sentences. 
This behavior has no business in FCP or in any other
protocol.

Response:
The sentences are changed to paraphrase SAM:
"All subsequent ... resume execution" 
	is changed to:
"When the task manager clears the auto contingent allegiance condition,
any task within that task set may be completed subjec to the rules
for task management specified by SAM."

114	Resource limitations (Technical)

Comment:
Clause 7.1.2, General, Since a new exchange is required to perform
several of these functions, the Initiator and Target must
never use their last exchange resource for a normal task. 
Unlike SIP/SPI, the maximum number of tasks that can be
outstanding is as much a function of the port you buy as the
firmware you use.  This restriction must be clearly stated
each time the problem arises.  In SIP/SPI the maximum number
of concurrent tasks is controlled strictly by firmware and
the protocol is not involved.  With FCP, the FC-PH protocol
can be a major limiting factor on the ability to start
concurrent tasks.

Response:
This comment is completely addressed by the resolution to
Comment 33. 

115	Correct N_Port term

Comment:
Clause 7.1.2, pages 24-25, Target Reset, para. 3, Change "N_Port" to
"FCP_Port" in 5 places.

Response:
Accepted.

116	Correct N_Port term

Comment:
Clause 7.1.2, page 25, Clear Task Set, para. 3, Change "N_Port" to
"FCP_Port" in 6 places.

Response:
Accepted.

117	Mandatory/Optional (Technical)

Comment:
Clause 7.1.2, page 25, Abort Task Set, para 1, Delete the two
sentences starting at "The bit is optional in FCP.".  FCP
cannot restrict those functions delegated to Initiators. 
Therefore,  it shall be permitted otherwise, incompatible FCP
devices result.  That is, one device uses the Abort Task Set
request and the other does not.  This incompatibility is not
acceptable.  Neither should FCP presume to know the protocol
and content of the requests since these are ULP functions and
not FC-4 functions.  Substitution of one action for the other
violates the layering rules we are trying to establish in
SCSI-3.

Response:
This question is under study.  Preliminary indications are
that some textual changes are desirable that would make
Abort Task mandatory and separate out the ABTS-LS function
as a separate protocol, called Recovery Abort, used by many
Task Management functions.

118	Correct N_Port term

Comment:
Clause 7.1.2, page 25, Abort Task Set, para. 3, Change "N_Port" to
"FCP_Port" in 3 places.

Response:
Accepted.

119	Change Abort Task (Technical)

Comment:
Clause 7.1.2, page 25-26, Abort Task, Implement it in the same way
as Terminate Task.  They are similar.  The procedure for
terminating a task and aborting a task are similar and are
logical functions, not FC-4 functions.  Handle them using a
similar protocol.

Response:
See Comment 112.  No change other than that proposed by Comment 117
is required.

120	Editorial, 7.1.2

Comment:
Clause 7.1.2, page 25, Abort Task, para. 1, line 6, Delete
"switching".  Change N_Port to FCP_Port in para 3 also.

Response:
Accepted

121	Editorial, 7.1.2

Comment:
Clause 7.1.2, page 26, Execution Management Codes, add "Byte 3" to
the end of the topic label.

Response:
Accepted.

122	Error behavior (Technical)

Comment:
Clause 7.1.2, page 26, Write Data.  FCP must specify the behavior
should an initiator set both the read and write data fields
to 1b.  No behavior is specified.  It is insufficient to
prohibit initiators from doing this.

Response:
Since this is a perfectly controlled bit by a trusted source
of information, the text of FC-PH with respect to the violation
of mandatory restrictions should be applied.  The text should be
placed in section 3.3.

"The term "shall" is used to indicate a mandatory rule.  If such a rule
is not followed, the results are unpredictable unless indicated otherwise."

123	Editorial 7.1.3

Comment:
Clause 7.1.3, para. 2, line 3, Change "nor examined by the Target"
to "and shall be ignored by the Target.  The shall is needed
here.

Response:
Accepted.

124	Clarify zero data length (Technical)

Comment:
Clause 7.1.4, Specify the relationship between zero and non-zero
values in this field and the Execution Management Codes in
Byte 3.

Response:
The text is clarified that:

a)	If Read Data and Write Data are both zero, FCP_DL shall be zero.
b)	If FCP_DL is zero, no data is expected to be transferred
	regardless of the state of the Read Data and Write Data bits.

125	Editorial 7.2

Comment:
Clause 7.2, para. 1, line 1, Change "responder" to "Target".

Response:
Accepted.

126	Optional/Mandatory

Comment:
Clause 7.2, That this is an optional  function is never stated.  If
required, it shall be used, but it is also permitted to not
use this IU with agreement from the other SCSI device.  This
needs to be stated in the text.

Response:
This is indicated in the second paragraph of the section.  No change is
required.

127	Length Error behavior (Technical)

Comment:
Clause 7.2, para. 3, line 3, Change "is required to" to "shall". 
Delete the last sentence in this paragraph since it is
implied by the shall added here.  If the initiator cannot
supply the entire length, what behavior does it do to inform
the Target and what is the target's behavior in return?

Response:
a)	Accept the change to use shall.
b)	The next sentence indicates that the initiator is expected to be
	able to supply all data within the limits of FCP_DL.  This is
	changed to a "shall" to answer the question.

128	Length behavior (Technical)

Comment:
Clause 7.2, para. 4, line 1, Change "target transfers to the
initiator" to "target shall transfer to the initiator in the
next IU".  If the target does not transfer the stated amount,
what is the initiator behavior?

Response:
a)	Accept the change to use shall.
Comment 122 defines the behavior of the system when "shall" rules
are violated.


129	Clarify Data Descriptor origin

Comment:
Clause 7.2, It should be stated that the contents of the first 12
bytes of  Table 19 are controlled by FC-PH and not subject to
change.  This is a side effect of using category 5.

Response:
The first line on page 27 will be modified to read:
"The first 8 bytes FCP_XFER_RDY payload are defined by FC-PH for
all Sequences of category 5.  The format of the payload is shown in
table 19."

130	Maximum burst length (Technical)

Comment:
Clause 7.2.2, para. 2, Add "The value in this field shall not exceed
the maximum burst length defined by the Disconnect-Reconnect
Page of MODE SELECT/MODE SENSE. (See 7.3, para. 2.)

Response:
Accepted.

131	Use of SEQ_ID (Technical)

Comment:
Clause 7.3, para. 3, line 1, The lowest relative offset field value
of an FCP_DATA IU is all that is required to reassemble.  The
SEQ_ID is only useful in an FCP_Port within an IU.

Response:
The SEQ_ID is used to verify that only one sequence is being transferred
within the exchange during streamed sequences.  No change is required.

132	RO Error Behavior (Technical)

Comment:
Clause 7.3. para. 3, line 4, What shall an initiator do if the RO
mismatch occurs on its end of the link?

Response:
This error and any other protocol verifications that the Exchange
Originator chooses to perform are outside the scope of the standard.

133	Length Error Behavior (Technical)

Comment:
Clause 7.3, para. 4, lines 2-3, Change "exact length" to "exact
location and length".

Response:
Accepted.

134	Overlayed Data (Technical)

Comment:
Clause 7.3, para. 5, The total amount of data transferred, at least
in SCSI-2 and SIP/SPI, represents only the maximum
displacement from the base address that any byte may be
placed by a target.  In SIP/SPI, a target is permitted to
retry, resend, and overlay data as long as this maximum
displacement is not violated and no unfilled displacements
are present.  

This rule should apply to FCP as well.  It is the target's
responsibility to get the data any way it can to the initiator. 
The major difficulty in SCSI-2 was that Modify Data Pointer was
optional and often not implemented by initiators.  That function
has been made mandatory by the targets ability to use any offset
it desires in a FCP_XFER_RDY IU.

Therefore, a target should only be limited by the prevailing rule
and not some artificial limitation.  The value in this field is
similar to the value a device driver gives to a Host Adapter. 
However, that value does not affect Target behavior.  Obviously,
if the displacement range were to be violated, the initiator has
many tools to stop the Target.  These should not be blind transfers
and overlapped transfers have been permitted and should be allowed
to continue.  Certainly, the mechanism for setting and adjusting
either the initiator or target addresses is platform dependent and
therefore under control at all times.

If the target executed a command and needs to transfer more data
than is allowed by the FCP_DL field, the ;command cannot end
normally.  It must end with more then just an indication in an FCP
dependent field.  

This function should not be exported to the opposite end of the
link.

Response:
Clause 7.3, paragraph 5, sentences "The target shall never ... FCP_RESID_OVER
bit." will be changed to read:

"The target shall never request or deliver data outside the buffer
length defined by FCP_DL.  If the command requested that data beyond
FCP_DL be transferred, the FCP_Status field shall contain the 
FCP_RESID_OVER bit."

The corresponding sentences in paragraph 6 are modified in a
similar manner.

These phrases together with the context resolve the comment.

135	Data Management (Technical)

Comment:
Clause 7.3, para. 6, page 28, The last transfer is signaled by
selecting a different IU.  the technical FC-PH text needs to
be changed to reflect IU choices.  The same argument about
FCP_DL applies to write operations.  The target is
responsible for its own internal operation.  If it has an
internal memory failure it should be allowed to retransmit
information.

The only limitation is that it not be allowed to violate the
maximum displacement rule in the comment above.  The initiator
should not care whether multiple transfers occur.  the target is
ultimately responsible to transfer all of the correct bytes from
displacement 0 to the maximum it determines from the CDB, not the
FCP_DL field.  If  the initiator disagrees, it has the tools to
stop the target.  This is an unnecessary rule and very limiting
compared to the other protocols.

The target should never transfer excess bytes and therefore it
should not have excess bytes to discard.  Clause 7.1.4 says that
it is the expected number of bytes.  It is probably better worded
as the maximum displacement to be transferred from a base address. 
This is consistent with how it has worked in the past.  Only the
displacement is tested for error, not multiple transfers of the
same data.

Response:
By choosing not to use the FCP_XFER_RDY IUs, the target forgoes
the opportunity of directing the initiator to retransmit write data
|from the same location.  The initiator still has the option to
pass data redundantly, but this can result in exceedingly bad
bus citizenship and should be managed very carefully or avoided.
The corrections of comments 130 and 134 address these questions.

136	Data Management (Technical)

Comment:
Clause 7.3, para. 7, page 28.  This paragraph is totally
inconsistent with the previous two paragraphs.  A Target
cannot both be allowed to overlay data and not exceed the
FCP_DL count.  There is a basic problem here.  If the target
is capable of selecting any relative offset within the valid
displacement range, an initiator is already prepared to put
data anywhere.  In case of a link error and overlay is not
permitted, a command must be aborted according to the present
rules since some of the data would be transmitted twice. This
seems too rigid to leave in FCP.  Since SIP/SPI initiators
are required to permit some overlay, then FCP initiators
should be required to support overlay.

Further, FCP is ;not complete id the text must depend on a vendor
unique response when an overlay occurs.  If overlay is or is not
to be permitted, just add it to the PRLI where the other
negotiations seems to occur.  A vendor unique response is
unacceptable a standard solution if it is needed is required.

Response:
The corrections provided for comments 130 and 134 bring this
paragraph into consistency with no additional changes.

While SIP architecturally allows overlay, SIP implementations do
not necessarily support it.  SAM states in section 2.1.1 that:
"If an SCSI-3 protocol supports random buffer access, as described
below, the offset and bute count specified for each data segment to
be transferred may overlap."  This statement clearly indicates that
there is no necessary requirement to support that.  SAM does not
require any indication of whether or not overlay is allowed.
FCP implementations have the same characteristics in this respect as
SIP implementations.

137	Data Management

Comment:
Clause 7.3, para. 8, page 28, line 2, Change "been transferred" to
"been transferred at least once".  This is consistent with
SIP/SPI behavior and other protocols.  Then the rule about
unused displacement ranges is totally correct.  If it cannot
be transferred error free, at least once, the command does
not report that data above the hole has been transferred. 
This is also totally consistent with the notion that the data
is not valid until after good status has been transferred
throughout SCSI.

There really seem no reason to have the FCP_DL value sent to the
Target at all.  If there is an error, the initiator must stop the
target with the tools it has.  Data overlay of all or part of the
data should not be a problem for either a target or an initiator
since it has been required of initiators and permitted by targets
since they SCSI targets to disconnect in SCSI-1.

Response:
The second sentence of paragraph 8 will be modified to read:
"By the time data transfer has been terminated, all data between the
offset of zero and the highest offset shall have been transferred."

The FCP_DL is a mechanism that provides useful data transfer
management information.  

138	RO Error Behavior (Technical)

Comment:
Clause 7.3, para. 9, line 2, Change "is" to "shall be".  Add a set
of rules about initiator and target behavior if the relative
offset is incorrect.

Response:
The entire paragraph should be deleted, since it is redundant with
information provided in 7.3 paragraph 3.

139	Editorial 7.3

Comment:
Clause 7.3, para 10, line 2, Change "effective" to "in effect".

Response:
Accepted.

140	Residual length (Technical)

Comment:
Clause 7.4, Table 20, FCP_RESID field and accompanying text.  Delete
this field.  This field is a function of the initiators
internal workings and should not be exported for target
control.  It is double work for some logical units since a
residual is reported in the Information Bytes of the sense
data.  Since the sense data is in the form of Autosense,
there is no reason to duplicate functions.

Response:
This field is exported to facilitate FC-PH management of
the data transfer, independent of the actual nature of the
SCSI command.  No change is required for this comment.

141	Data Management (Technical)

Comment:
Clause 7.4.1, Byte 2, Bits 3-2,  These fields are not really needed
as stated above.  The basis for any calculation is an
estimated value.  The real value for the data length only
comes from the CDB itself and other attributes known to the
Logical Unit.  Therefore, if the initiator sets its FCP_DL
value on platform boundaries of 4 or 8 bytes, almost every
command could end with a FCP_RESID_UNDER indication with no
real errors in the system.  For device classes other than
disk this could be a common occurrence.  But those device
classes already have the mechanisms to report residual
counts.  This is redundant and not properly a logical unit
function to report in this manner since both the source and
reporting are outside the bounds of the command structure of
SCSI.  If we need to invent new commands for some reason then
lets do that, but not invent a protocol specific command
subset.

Response:
The estimated value is a value explicitly calculated as part of
the buffer allocation structure of the initiator.  The data management
is overseen by command independent layers of the SCSI function.
This provides the proper limiting information and error reporting
for these sublayers.  No change is required because of this comment.

142	Residual length (Technical)

Comment:
Clause 7.4.2, para. 1, line 4, Change "value is not be valid" to
"value is not valid".  Note that for the sequential device
class, the control of the residual counts is fully
architected within the command set.  The presence of the
FCP_RESID requires reporting items in a mandatory fashion
that have been eliminated by agreements between the involved
parties.  This field should also be deleted.  This becomes a
performance issue once again where it was fixed in SCSI-2. 
Any non-zero value in FCP_STATUS requires analysis even when
the status is GOOD as it is with may tape operations where
the lengths would not match under this scheme.

Response:
a)	Accepted.
b)	See comment 141.  No change is required because of this comment.

143	Overlapping data (Technical)

Comment:
Clause 7.4.2, paras. 2-3, The calculation of FCP_DL does not permit
overlaying of data as permitted in clause 7.3.  This
discrepancy and inconsistency must be corrected.

Response:
Paragraph 2, first sentence will be corrected to say:  "If the
FCP_RESID_UNDER bit is set, a transfer that did not fill the 
buffer to the expected displacement FCP_DL was performed and the
value of FCP_RESID is a number equal to: ... "
Paragraph 3, first sentence will be corrected to say:  "If the FCP_RESID_OVER
bit is set, the transfer was truncated because the data transfer required
by the SCSI command extended beyond the displacement value of FCP_DL."

144	Editorial 7.4.4

Comment:
Clause 7.4.4, para. 2, line 2, Add a period at the end of the
sentence.

Response:
Accepted.

145a	SCSI-2 (Technical)

Comment:
Clause 7.4.5, para. 1, line 1, There should be no reference to SCSI-
2 sense data,  SPC is the only valid reference point for this
information.  The rules about minimums and maximums and
presentation should be deferred to SPC and the text removed
|from FCP.

Response:
a)	It is assumed that this actually references 7.4.6.
	In the absence of any drafts of SPC, SCSI-2 is a valid and
	useful reference.  This is especially true, since SPC will be
	faithfully reflecting SCSI-2.  
b)	The sentence reflecting minimums will be removed.
c)	SAM has been modified to allow FCP_SNS_INFO only with
	Check Condition or Command Terminated Status.  The text
	will be modified to reflect this change.

145b	FCP_SNS_INFO (Technical)


Comment:
In Clause 7.4.5 or related clauses, there is no requirement that I can 
determine that FCP_SNS_INFO must be used at all times.  That is, if a CHECK
CONDITION or COMMAND TERMINATED status occurs, the logical unit
could revert to waiting for the Initiator to request the sense
data.  That option should be available to logical units and FCP
should not force a behavior.  It can provide a note that sending
Autosense data is encouraged, but it has not right to demand it.

Response:
FCP uses autosense.  No change is required.

146	Include examples in annex

Comment:
Annex A.  This should have clause 5.3 incorporated into it
and the examples removed from the main body of the standard.

Response:
An annex (possibly not Annex A) will be prepared to receive clause 5.3.

147	Clarify examples

Comment:
Annex A,  This Annex should indicate that its examples are
for Class 2 only.

Response:
Accepted.  The titles of the figures will be modified to indicate
that this represents class 2 behavior.

148	Addressing model (Technical)

Comment:
Annex B.  Delete this annex.  Any discussion about logical
unit addressing belongs in SAM, not here.  FCP is required to
provide a field up to 64 bits long.  It has provided the
maximum length field.  Any discussion about the structure of
the field is inappropriate in any of the protocol standards. 
If a proposal is required for SAM, then this may be a basis
for that.  However, this structure is not generally
applicable and may be best delegated to SAM or even SCC.

Response:
This annex has proven useful to many implementors.  Since it is
informative and given as an example, it should not be removed.
No change is required.
The normative specification of a model like this will be
contained in SCC.



Comments generated by Hewlett Packard

149	Annex A typographical error

Comment:
The examples in Annex A shows class 2 examples using the FCP protocol to perform
reads and writes.  These examples have an incorrect usage of the EOF 
delimiter.  The examples currently indicate that the EOFt delimiter 
is used on the last frame of a sequence.  EOFn should be used when sending
the last frame of a sequence, EOFt should be used when sending the ACK for
the last frame of the sequence.

Response:
The error will be corrected.


Comments generated by IBM


150	Dual port reset (Technical)

Comment:
FCP has no method of resetting an alternate port of a dual port SCSI
device without affecting the port being used. Since Parallel SCSI has this
capability (using a message), FCP should also. A currently reserved bit
of the Task Management Flags field (Byte 2 of FCP_CNTL, p. 23) could be
used for this task. The function should reset all other ports of a
multiport device.

Proposed Response:
SAM does not presently specify the "Bus Device Reset Other Port"
function.  I would assume that is a "Target Reset Other Port" function
in SAM terms.  Since FCP is likely to have multi-port capability,
either the FCP_CDB field or the FCP_DL field should be used to
specify some identifier for the other port.  The identifier should
probably be the 64-bit WWN for the port.

Since the specification of this function is so incomplete in the
defining documents, I would prefer to put this in either
an informative annex or a later edition of the FCP.

151	Command State after Clear ACA (Technical)

Comment:
FCP states that ALL commands are resumed after a Clear ACA task
management function is received. The SCSI Architecture Model (SAM)
states that only non-ACA tagged commands should be resumed and ACA
tagged commands should be aborted. FCP should be consistent with
SAM. (Please see p. 24, Clear ACA.)

Proposed Response:
Accepted.  The paragraphs will be corrected to reflect these
concepts.


Comments generated by Unitrode

152	SAM approval

Comment:
We would still like to have SAM approved first.

Proposed Response:
It would be nice.  No change is required in the FCP to address
this comment.

153	Table reference errors

Comment:
5.3.9 Table 13 is referenced as table 12
6.2.1 Table 15 is referenced as table 14
7.4.1 There is no reference to table 21 as in all other sections.

Response:
Accepted.


Comments generated by Seagate

154	Document reference

Comment:
The referenced document should be rev 8 rather than 7.

In this instance my vote is an organizational one since the balance of
the comments were provided by engineers developing our FCP design.
Resolution of the following comments would allow my vote to be changed
to yes.

Response:
Accepted.

155	Untagged operation (Technical)

Comment:
Page 17, Section 5.5.10,  Use OX_ID=FFFF to indicate an untagged 
command, and drop the "untagged"
task management bit (page 24, section 7.1.2).  Such usage is consistent
with FC-PH section 18.9.

Response:
If the OX_ID is unassigned as specified in FC-PH 18.9, then no
Recovery Abort can be successfully associated with the untagged
command.  The use of a defined OX_ID and an untagged indication in the
FCP_CNTL field is probably safer for generic error recovery.
No change is required for this comment.

156	Editorial, 6.1

Comment:
Page 18, Section 6.1, Para 5
	"sate" s/b "state"
	"effected" s/b "affected"

Response:
Accepted.

157	PRLI Clarification 

Comment:
Page 18, Section 6.1, Para 5
Needs clarification:  by stating that "Mode Select parameters will assume
their default or saved states for that image pair" it is implied that
other image pairs are unaffected, but this is inconsistent with the
target being in "the same state as after a power-on or hard reset." 
Also, it is not true that the target will be in the same state as after
a power-on since login sessions with other initiators must survive.  

Response:

158	Error Codes (Technical)

Comment:
Page 18, Section 6.1, Para 5
What Additional Sense Code should be returned with the Unit Attention? 

Response:

159	PRLI Clarification (Technical)

Comment:
Page 18, Section 6.1
If targets must dump tasks for other initiators on PRLI, they should be
aborted with ABTS-LS as required for Target Reset and PRLO,  rather than
just being cleared.

Response:

160	PRLI Clarification (Technical)

Comment:
Page 18, Section 6.1
Having the target dump all tasks and reservations for all initiators when
an initiator does a PRLI accomplishes nothing and wastes time.  The new
initiator can issue a Target Reset after PRLI if it wants the target in
this state.  The appropriate place to behave this way, and this should
be specified in FCP, is after a target NL_Port engages in loop
re-initialization, or a target FCP ports participates in the Link Reset
protocol.

Response:  

161	PRLI Clarification (Technical)

Comment:
Page 18, Section 6.1, Para 5
To summarize comments on this section, suggest wording paragraph 5 to
have the following meaning:  

 Immediately after the execution of a PRLI, a target will have no tasks,
reservations, or status present for the other port involved in the PRLI. 
Mode Select parameters will assume their default or saved states for that
image pair.   Tasks, reservations, status, and Mode Select parameters for
other initiators are not affected.  A unit attention condition as defined
in the SAM is generated by the target port for the initiator port with
Additional Sense Code indicating power-on reset or hard reset.  A target
port shall not generate a unit attention condition for  initiators which
are already logged in.

Response:

162	Use of Initiator/Target bits (Technical)

Comment:
Page 19, Section 6.1.1
Unclear whether usage of AEN or other role-reversals would require both
bits to be set by both targets and initiators.  Information is lost if
so: a host is interested in who is primarily an target, not in who is a
target only for the purposes of AEN.  Could define new bit flags to
indicate whether limited role reversals appropriate to their primary
functions are supported.  Better yet, reword as follows:

Word 3, Bit 5:  Initiator Function

When this bit is set to 1, the process is indicating that it operates as
a SCSI Initiator.  ... Initiators may implement some target functions
without setting the Target Function bit;  the use of these capabilities
by a target is defined by Mode Select parameters.

Word 3, Bit 4:  Target Function

When this bit is set to 1, the process is indicating that it operates as
a SCSI target. ... Targets may implement some initiator functions without
setting the Initiator Function bit; the use of these capabilities by a
target is defined by Mode Select parameters. 

Response: 

163	PRLO Clarification (Technical)

Comment:
Page 20, Section 6.2 (PRLO)
The state after a PRLO is NOT equivalent to a power-on or hard reset, as
other ports are not logged out.

164	PRLO Clarification

Comment:
Page 20, Section 6.2
The effect on Mode Select parameters for other initiators is not clear. 
Should behave in same manner as PRLI.  

Response:

165	PRLO Clarification (Technical)

Comment:
Page 20, Section 6.2
No reason to abort all tasks from all initiators, just the one which is
logging out.  There is no need to use ABTS on these; they may simply be
cleared.

Response:

166	PRLO Clarification 

Comment:
Page 20, Section 6.2
If all tasks from all initiators are to be aborted, reference should be
made to 7.1.2.  This is a better description of using ABTS than is given
in this paragraph.

Response:

167	ABTS Proposal

Comment:
Page 25, Section 7.1.2,  ABTS protocol
FCP requires the use of the ABTS-LS protocol, but it is not fully
described in any standards document. This really belongs in FC-PH, but
for now perhaps it would be appropriate as an Annex in FCP.

Response:
Under study.  See comment 117.


168	Missing from FC-PH (Technical)

Comment:
The following feature is not currently specified in FC-PH but is advocated
by FCSI-101 ("FCSI Common FC-PH Feature Sets Used in Multiple Profiles",
page 10):  
ABTS may be sent at any time by either side, regardless of
Sequence Initiative or Credit.

Response:
Under study.  See comment 117

169	Missing from FC-PH (Technical)

Comment:
The following feature is not currently specified in FC-PH but is advocated
by FCSI-101 ("FCSI Common FC-PH Feature Sets Used in Multiple Profiles",
page 10):  
rules for setting SEQ_ID and SEQ_CNT by
a port which has not yet sent a sequence in the Exchange to be aborted.

Response:
Accepted.  Will be included with the resolution of comment 117.

170	Missing from FC-PH (Technical)

Comment:
The following feature is not currently specified in FC-PH but is advocated
by FCSI-101 ("FCSI Common FC-PH Feature Sets Used in Multiple Profiles",
page 10): 
BA_ACC frame should set SEQ_CNT_LO to 0 and SET_CNT_HI to FFFF.

Response:
Accepted.  Will be included with the resolution of comment 117.


Comments Identified by Editor during analysis of review questions

171	Abort

Comment:
Table 2 of section 4.3 shows ABORT TASK SET as a Required or Mandatory
function.  The text correctly indicates that it is an Optional function.

Response:
ABORT TASK SET will be specified as Optional in Table 2.

172	Standard capitalization

Comment:
SAM has determined that the words "target", "initiator", and
"logical unit" are not capitalized except in titles and at the
beginning of sentences.

Response:
Accepted.  Numerous changes required.

173	command byte count

Comment:
Text should be placed in 7.1.4 to indicate that the FCP_DL (which
is the SAM command byte count) contains a count of the greatest
number of data bytes expected to be transfered to or from the
application client data buffer by the SCSI CDB.

Response:
Accepted.




More information about the T10 mailing list