FCP Letter Ballot Results

John Lohmeyer jlohmeye at ncr-mpd.FtCollinsCO.NCR.COM
Mon Mar 21 11:30:33 PST 1994

X3T10 Letter Ballot Results on FCP: 

             47 Yes, 2 No, 0 Abstain, 11 Did not return ballot

Yes, with 
comment:          IBM, Unitrode

No:               FSI, Seagate

Did not 
return ballot:    Advanced Micro Devices, Cirrus Logic,   Conner
                  Peripherals, Distributed Processing Technology,
                  Harting Electronik, Maxtor, National
                  Semiconductor, Oak Technology, P. E. Logic,
                  Rancho Technology, and Samsung

FCP has passed this ballot, but X3T10 must make an effort to
resolve the comments.  Since Bob Snively, FCP Editor, cannot
complete this effort prior to the mailing deadline, the current plan
is for Bob to mail a revised FCP document directly to the X3T10
members at least two weeks prior to the May '94 X3T10 meeting.

A meeting to develop the FCP responses will be held in conjuction with
the April X3T11 and X3T12 meetings in Seattle.  The meeting is planned for
Monday, April 18th.  Contact Bob Snively for details.

Expect motions to approve the FCP responses and to approve the
substantive changes to FCP at the May meeting.

IBM comments:

1.    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.  This function should reset all other
      ports of a multiport device.

2.    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.)

Unitrode comments:

We would still like to have SAM approved first.

Minor editorial things:

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.

FSI comments:

The following comments are provided to support a "NO" vote for Project
993D, Revision 8.

1. (E)      Foreword, Line 2, Change "command," to "commands,".

2. (E)      Introduction, Para. 1, Line 3, Change "performance serial" to
            "performance Fibre Channel".

3. (E)      Introduction, Para. 2, Line 1, Change "Sequences" to
            "Exchanges and Information Units".

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

5. (T)      2 Normative References, Delete reference to SCSI-2 Standard. 
            It does not apply to this standard.  Only SAM applies.

6. (E)      2 Normative References, Update Revision Level on FC-AL to

7. (E)      2 Normative References, Update Revision Level on FC-FG to

8. (E)      2 Normative References, Update Revision Level on FC-SB to

9. (E)      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.

10. (E)     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

11. (T)     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.

12. (E)     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.  

13. (T)     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.

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

15. (T)     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

      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.

16. (E)     3.1.16, Delete "as a single sequence".  See Comment 9.

17. (T)     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.

18. (T)     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.

19. (E)     3.1.22, Add the source of this borrowed definition (FC-PH or

20. (T)     3.1.23, Add the definition of NL_Port.

21. (T)     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.)

22. (T)     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.

23. (T)     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
24. (T)     3.1.29, Change "commands" to "tasks" or "I/O operations".

25. (E)     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.

26. (E)     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

      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.

27. (E)     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,

28. (E)     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.

29. (T)     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".

30. (T)     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.

31. (E)     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.

32. (E)     Table 1, line 3, Change "sequence" to "Information Unit".

33. (T)     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.

34. (E)     Clause 4.2.  This clause needs to be marked as "Informative".

35. (E)     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.

36. (E)     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.

37. (E)     Clause 4.2, para 2, line 6, Change "transfers" to "IUs".

38. (E)     Clause 4.2, para. 3, line 3, Change "described" to

39. (E)     Clause 4.2, para. 3, line 4, Change "solicited data sequence
            " to "Solicited Data IU".

40. (E)     Clause 4.2, para. 3, line 5, Change "information" to

41.`(E)     Clause 4.2, para. 3, line 6, Change "described" to

42. (E)     Clause 4.2, para. 3, line 6, Change "solicited data sequence"
            to "Solicited Data IU".

43. (E)     Clause 4.2, para. 3, line 7, Change "information" to

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

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

46. (E)     Clause 4.2, para. 4, line 1, Change "command service request"
            to "Command Service Request".

47. (E)     Clause 4.2, para. 4, lines 2-3, Change "Status Byte" to

48. (E)     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.". 

49. (E)     Clause 4.2, para. 5, Page 7, Change "FCP I/O Operation" to

50. (E)     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.".

51. (T)     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.

52. (E)     Clause 4.2, para. 8, line 2, Change "sequences of FCP I/O
            Operations" to "IUs of FCP".

53. (T)     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.

54. (T)     Clause 4.3, Page 7, para.2, line 3, Change "sequence" to

      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. 

55. (E)     Clause 4.3, para. 2, line 3, Change "CDB of" to "FCP_CDB
            field in".

56. (E)     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.

57. (T)     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 FCP FC-4 must
            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.

58. (T)     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.

59. (T)     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.

60. (E)     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. 

61. (E)     Clause 5.1, page 9, para. 1, line 1, Change "fibre channel"
            to "Fibre Channel".

62. (T)     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.

63. (E)     Clause 5.1, para. 2, line 1, Delete "SCSI Devices and".  

64. (T)     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.

65. (T)     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.  

66. (E)     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.

67. (T)     Table 3, page 10, Note 4, Change T10 to T11.

68. (T)     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.

69. (T)     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.

70. (E)     5.3.  Move this entire clause to Annex A.  It is purely
            exemplary material.

71. (E)     Tables 5 - 13, Change "UI" to "IU".

72. (T)     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

73. (E)     5.3, para. 1, line 4, Delete the last sentence.

74. (T)     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.

75. (T)     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.

76. (T)     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.

77. (T)     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.

78. (E)     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.

79. (T)     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.  

80. (T)     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.

81. (E)     6, para 2, line 5, Change "acceptance" to "acceptance or
            rejection".  On the same line, change "acceptance or
            rejection to" to "response to".

82. (T)     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?

83. (E)     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.

84. (T)     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

85. (T)     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.  Do other protocols have
            protocol specific responses not yet proposed to X3T10?

86. (T)     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.

87. (T)     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

      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.

88. (E)     6.1, para. 5, line 3, Change "sate" to "state".

89. (T)     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

90. (T)     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.

91. (T)     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?  

92. (T)     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.

93. (E)     6.1.1, Word 0, Bits 3-24, para. 1, line 1, Change "16-byte
            set" to "PRLI".

94. (T)     6.1.1, Word 0, Bit 15, paras. 1-2, Change "word 2" to "word

95. (T)     6.1.1, Word 0, Bit 14, paras. 1-2, Change "word 3" to "word

96. (T)     6.1.1, Word 3, Bit 4, para 1, line 2, Change "2 and 3" to "5
            and 4".

97. (T)     6.1.1, Word 3, Bit 4, para. 1, top of page 20, Define a
            response of FCP_RJT.

98. (E)     6.1.1, Word 3, Bit 3, para. 1, line 2, Change "data are" to
            "data shall be".

99. (E)     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

100.(T)     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.

101.(E)     6.1.1, Word 3, Bit 2, para. 1, line 2, Change "data are" to
            "data shall be".

102.(E)     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

103.(T)     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..

104.(T)     6.1.1, Word 2, Bit 2, para. 1, There seems to be no rationale
            for unconditionally using I^ or I& 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.  

105.(E)     6.2, para. 1, line 2, Change "pairs" to "pair.  No case for
            sending multiple pairs has been established.

106.(T)     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. 

107.(E)     6.2.1, Word 0, Bits 31-24, Change "16 byte set" to "PRLO".

108.(T)     6.2.1, Word 0, correct all word references for words 1 and 2.

109.(E)     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.

110.(T)     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.

111.(T)     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.

112.(T)     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.

113.(T)     7.1.2, page 24, CLEAR ACA, Delete the last two sentences. 
            This behavior has no business in FCP or in any other

114.(T)     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.

115.(E)     7.1.2, pages 24-25, Target Reset, para. 3, Change "N_Port" to
            "FCP_Port" in 5 places.

116.(E)     7.1.2, page 25, Clear Task Set, para. 3, Change "N_Port" to
            "FCP_Port" in 6 places.

117.(T)     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

118.(E)     7.1.2, page 25, Abort Task Set, para. 3, Change "N_Port" to
            "FCP_Port" in 3 places.

119.(T)     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.

120.(E)     7.1.2, page 25, Abort Task, para. 1, line 6, Delete
            "switching".  Change N_Port to FCP_Port in para 3 also.

121.(E)     7.1.2, page 26, Execution Management Codes, add "Byte 3" to
            the end of the topic label.

122.(T)     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.

123.(E)     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

124.(T)     7.1.4, Specify the relationship between zero and non-zero
            values in this field and the Execution Management Codes in
            Byte 3.

125.(E)     7.2, para. 1, line 1, Change "responder" to "Target".

(E)     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.

127.(T)     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?

128.(T)     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?

129.(E)     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.

130.(T)     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.)

131.(T)     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.

132.(T)     7.3. para. 3, line 4, What shall an initiator do if the RO
            mismatch occurs on its end of the link?

133.(T)     7.3, para. 4, lines 2-3, Change "exact length" to "exact
            location and length".

134.(T)     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

135.(T)     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

      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.

136.(T)     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.

137.(E)     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.

138.(T)     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.

139.(E)     7.3, para 10, line 2, Change "effective" to "in effect".

140.(T)     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.

141.(T)     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

142.(T)     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.

143.(T)     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.

144.(E)     7.4.4, para. 2, line 2, Add a period at the end of the

145.(T)     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.

      Also, 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.

146.(E)     Annex A.  This should have clause 5.3 incorporated into it
            and the examples removed from the main body of the standard.

147.(E)     Annex A,  This Annex should indicate that its examples are
            for Class 2 only.

148.(T)     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.

Seagate comments:

1) 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.

T 001  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.

E 002  Page 18, Section 6.1, Para 5

"sate" s/b "state"
"effected" s/b "affected"

E 003 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.  

T 004 Page 18, Section 6.1, Para 5

What Additional Sense Code should be returned with the Unit Attention? 

T 005 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.  

T 006 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

T 007 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.

T 008 Page 19, Section 6.1.1,  Initiator Function and Target Function

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.  

T 009 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.

E 010 Page 20, Section 6.2

The effect on Mode Select parameters for other initiators is not clear. 
Should behave in same manner as PRLI.  

T 011 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

E 012 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.

E 013 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.

The following features are not currently specified in FC-PH but 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; rules for setting SEQ_ID and SEQ_CNT by
a port which has not yet sent a sequence in the Exchange to be aborted; 
BA_ACC frame should set SEQ_CNT_LO to 0 and SET_CNT_HI to FFFF.

                        END OF FCP LETTER BALLOT COMMENTS
John Lohmeyer                      E-Mail:  John.Lohmeyer at FtCollinsCO.NCR.COM
NCR Microelectronics                Voice:  719-573-3362
1635 Aeroplaza Dr.                    Fax:  719-597-8225
Colo Spgs, CO 80916              SCSI BBS:  719-574-0424 300--14400 baud

More information about the T10 mailing list