doc: Add RFC documents

1 files changed, 2131 insertions, 0 deletions

diff --git a/doc/rfc/rfc5048.txt b/doc/rfc/rfc5048.txt
new file mode 100644
index 0000000..a586df5
--- /dev/null
+++ b/doc/rfc/rfc5048.txt
@@ -0,0 +1,2131 @@
+
+
+
+
+
+
+Network Working Group                                M. Chadalapaka, Ed.
+Request for Comments: 5048                           Hewlett-Packard Co.
+Updates: 3720                                               October 2007
+Category: Standards Track
+
+
+           Internet Small Computer System Interface (iSCSI)
+                     Corrections and Clarifications
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   The Internet Small Computer System Interface (iSCSI) is a SCSI
+   transport protocol and maps the SCSI architecture and command sets
+   onto TCP/IP.  RFC 3720 defines the iSCSI protocol.  This document
+   compiles the clarifications to the original protocol definition in
+   RFC 3720 to serve as a companion document for the iSCSI implementers.
+   This document updates RFC 3720 and the text in this document
+   supersedes the text in RFC 3720 when the two differ.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Definitions, Acronyms, and Document Summary .....................3
+      2.1. Definitions ................................................3
+      2.2. Acronyms ...................................................4
+      2.3. Clarifications, Changes, and New Semantics .................5
+   3. iSCSI Semantics for SCSI Tasks ..................................7
+      3.1. Residual Handling ..........................................7
+           3.1.1. Overview ............................................7
+           3.1.2. SCSI REPORT LUNS and Residual Overflow ..............7
+      3.2. R2T Ordering ...............................................9
+      3.3. Model Assumptions for Response Ordering ....................9
+           3.3.1. Model Description ..................................10
+           3.3.2. iSCSI Semantics with the Interface Model ...........10
+           3.3.3. Current List of Fenced Response Use Cases ..........11
+   4. Task Management ................................................12
+      4.1. Requests Affecting Multiple Tasks .........................12
+           4.1.1. Scope of Affected Tasks ............................12
+           4.1.2. Clarified Multi-Task Abort Semantics ...............13
+           4.1.3. Updated Multi-Task Abort Semantics .................14
+
+
+
+Chadalapaka                 Standards Track                     [Page 1]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+           4.1.4. Affected Tasks Shared across RFC 3720 and
+                  FastAbort Sessions .................................16
+           4.1.5. Implementation Considerations ......................17
+           4.1.6. Rationale behind the New Semantics .................17
+   5. Discovery Semantics ............................................19
+      5.1. Error Recovery for Discovery Sessions .....................19
+      5.2. Reinstatement Semantics of Discovery Sessions .............19
+           5.2.1. Unnamed Discovery Sessions .........................20
+           5.2.2. Named Discovery Sessions ...........................20
+      5.3. Target PDUs during Discovery ..............................20
+   6. Negotiation and Others .........................................21
+      6.1. TPGT Values ...............................................21
+      6.2. SessionType Negotiation ...................................21
+      6.3. Understanding NotUnderstood ...............................21
+      6.4. Outstanding Negotiation Exchanges .........................22
+   7. iSCSI Error Handling and Recovery ..............................22
+      7.1. ITT .......................................................22
+      7.2. Format Errors .............................................22
+      7.3. Digest Errors .............................................22
+      7.4. Message Error Checking ....................................23
+   8. iSCSI PDUs .....................................................23
+      8.1. Asynchronous Message ......................................23
+      8.2. Reject ....................................................24
+   9. Login/Text Operational Text Keys ...............................24
+      9.1. TaskReporting .............................................24
+   10. Security Considerations .......................................25
+   11. IANA Considerations ...........................................26
+      11.1. iSCSI-Related IANA Registries ............................26
+      11.2. iSCSI Opcodes ............................................26
+      11.3. iSCSI Login/Text Keys ....................................28
+      11.4. iSCSI Asynchronous Events ................................30
+      11.5. iSCSI Task Management Function Codes .....................31
+      11.6. iSCSI Login Response Status Codes ........................32
+      11.7. iSCSI Reject Reason Codes ................................34
+      11.8. iSER Opcodes .............................................35
+   12. References ....................................................36
+      12.1. Normative References .....................................36
+      12.2. Informative References ...................................36
+   Acknowledgements ..................................................37
+
+
+
+
+
+
+
+
+
+
+
+
+Chadalapaka                 Standards Track                     [Page 2]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+1.  Introduction
+
+   Several iSCSI implementations have been built since [RFC3720] was
+   published and the iSCSI community is now richer by the resulting
+   implementation expertise.  The goal of this document is to leverage
+   this expertise both to offer clarifications to the [RFC3720]
+   semantics and to address defects in [RFC3720] as appropriate.  This
+   document intends to offer critical guidance to implementers with
+   regard to non-obvious iSCSI implementation aspects so as to improve
+   interoperability and accelerate iSCSI adoption.  This document,
+   however, does not purport to be an all-encompassing iSCSI how-to
+   guide for implementers, nor a complete revision of [RFC3720].
+   Instead, this document is intended as a companion document to
+   [RFC3720] for the iSCSI implementers.
+
+   iSCSI implementers are required to reference [RFC3722] and [RFC3723]
+   in addition to [RFC3720] for mandatory requirements.  In addition,
+   [RFC3721] also contains useful information for iSCSI implementers.
+   The text in this document, however, updates and supersedes the text
+   in [RFC3720] whenever there is such a question.
+
+2.  Definitions, Acronyms, and Document Summary
+
+2.1.  Definitions
+
+   I/O Buffer
+      A buffer that is used in a SCSI Read or Write operation so SCSI
+      data may be sent from or received into that buffer.  For a read or
+      write data transfer to take place for a task, an I/O Buffer is
+      required on the initiator and at least one is required on the
+      target.
+
+   SCSI-Presented Data Transfer Length (SPDTL)
+      SPDTL is the aggregate data length of the data that the SCSI layer
+      logically "presents" to the iSCSI layer for a Data-In or Data-Out
+      transfer in the context of a SCSI task.  For a bidirectional task,
+      there are two SPDTL values -- one for Data-In and one for Data-
+      Out.  Note that the notion of "presenting" includes immediate data
+      per the data transfer model in [SAM2], and excludes overlapping
+      data transfers, if any, requested by the SCSI layer.
+
+   Third-party
+      A term used in this document to denote nexus objects (I_T or
+      I_T_L) and iSCSI sessions that reap the side effects of actions
+      that take place in the context of a separate iSCSI session, while
+      being third parties to the action that caused the side effects.
+      One example of a third-party session is an iSCSI session hosting
+
+
+
+
+Chadalapaka                 Standards Track                     [Page 3]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+      an I_T_L nexus to an LU that is reset with an LU Reset TMF via a
+      separate I_T nexus.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.2.  Acronyms
+
+   Acronym        Definition
+   -------------------------------------------------------------
+
+   EDTL           Expected Data Transfer Length
+
+   IANA           Internet Assigned Numbers Authority
+
+   IETF           Internet Engineering Task Force
+
+   I/O            Input - Output
+
+   IP             Internet Protocol
+
+   iSCSI          Internet SCSI
+
+   iSER           iSCSI Extensions for RDMA
+
+   ITT            Initiator Task Tag
+
+   LO             Leading Only
+
+   LU             Logical Unit
+
+   LUN            Logical Unit Number
+
+   PDU            Protocol Data Unit
+
+   RDMA           Remote Direct Memory Access
+
+   R2T            Ready To Transfer
+
+   R2TSN          Ready To Transfer Sequence Number
+
+   RFC            Request For Comments
+
+   SAM            SCSI Architecture Model
+
+   SCSI           Small Computer Systems Interface
+
+
+
+
+Chadalapaka                 Standards Track                     [Page 4]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+   SN             Sequence Number
+
+   SNACK          Selective Negative Acknowledgment - also
+                  Sequence Number Acknowledgement for data
+
+   TCP            Transmission Control Protocol
+
+   TMF            Task Management Function
+
+   TTT            Target Transfer Tag
+
+   UA             Unit Attention
+
+2.3.  Clarifications, Changes, and New Semantics
+
+   This document specifies certain changes to [RFC3720] semantics as
+   well as defines new iSCSI semantics.  In addition, this document also
+   clarifies the [RFC3720] semantics.  This section summarizes the
+   contents of the document, categorizing each section into one or more
+   of a clarification, change, or new semantic.
+
+      Section 3.1.1: Clarification on iSCSI residuals computation
+      general principles
+
+      Section 3.1.2: Clarification on iSCSI residuals computation with
+      an example
+
+      Section 3.2: Clarification on R2T ordering requirements
+
+      Section 3.3: New Semantics for Response Ordering in multi-
+      connection iSCSI sessions
+
+      Section 4.1.2: Clarifications, changes, and new semantics on
+      multi-task abort semantics that all implementations must comply
+      with
+
+      Section 4.1.3: Changes and new semantics (FastAbort semantics) on
+      multi-task abort semantics that implementations should use for
+      faster error recovery
+
+      Section 4.1.3.1: Changes in iSCSI clearing effects semantics
+      resulting from new FastAbort semantics
+
+      Section 4.1.4: New Semantics on third-party session interactions
+      with the new FastAbort semantics
+
+
+
+
+
+
+Chadalapaka                 Standards Track                     [Page 5]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+      Section 4.1.5: Clarification on implementation considerations
+      related to outstanding data transfers in order to realize correct
+      iSCSI protocol behavior
+
+      Section 4.1.6: Clarification on the intent behind FastAbort
+      semantics (not clarifications to [RFC3720] semantics)
+
+      Section 5.1: Clarification on error recovery semantics as
+      applicable to Discovery sessions
+
+      Section 5.2.1: Clarification and new semantics on applying the
+      Initiator Session Identifier (ISID) RULE ([RFC3720]) to Unnamed
+      Discovery Sessions
+
+      Section 5.2.2: Clarification on applying the ISID RULE to Named
+      Discovery Sessions
+
+      Section 5.3: Clarification on allowed PDU types and target Logout
+      notification behavior on a Discovery session
+
+      Section 6.1: Clarification on the legality of the Target Portal
+      Group Tag (TPGT) value of zero
+
+      Section 6.2: Clarification on the negotiating order of SessionType
+      with respect to other keys
+
+      Section 6.3: Clarification on the NotUnderstood negotiation
+      response on declarative keys and the implied semantics
+
+      Section 6.4: Clarification on the number of legal outstanding
+      negotiation PDUs (Text or Login-related)
+
+      Section 7.1: Clarification on usage of the ITT value of 0xffffffff
+
+      Section 7.2: Clarification on what constitutes format errors for
+      the purpose of error recovery defined in [RFC3720]
+
+      Section 7.3: Change in error recovery semantics for the case of
+      discarding unsolicited PDUs
+
+      Section 7.4: Clarification on the intended level of error checking
+      on inbound PDUs
+
+      Section 8.1: New semantics for a new AsyncEvent code
+
+      Section 8.2: Change of legal status for Reject reason code 0x0b;
+      it is now deprecated
+
+
+
+
+Chadalapaka                 Standards Track                     [Page 6]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+      Section 9.1: New semantics for a new text key TaskReporting
+
+3.  iSCSI Semantics for SCSI Tasks
+
+3.1.  Residual Handling
+
+   Section 10.4.1 of [RFC3720] defines the notion of "residuals" and
+   specifies how the residual information should be encoded into the
+   SCSI Response PDU in the Counts and Flags fields.  Section 3.1.1
+   clarifies the intent of [RFC3720] and explains the general
+   principles.  Section 3.1.2 describes the residual handling in the
+   REPORT LUNS scenario.
+
+3.1.1.  Overview
+
+   SCSI-Presented Data Transfer Length (SPDTL) is the term this document
+   uses (see Section 1.1 for definition) to represent the aggregate data
+   length that the target SCSI layer attempts to transfer using the
+   local iSCSI layer for a task.  Expected Data Transfer Length (EDTL)
+   is the iSCSI term that represents the length of data that the iSCSI
+   layer expects to transfer for a task.  EDTL is specified in the SCSI
+   Command PDU.
+
+   When SPDTL = EDTL for a task, the target iSCSI layer completes the
+   task with no residuals.  Whenever SPDTL differs from EDTL for a task,
+   that task is said to have a residual.
+
+   If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in the
+   SCSI Response PDU as specified in [RFC3720].  The Residual Count MUST
+   be set to the numerical value of (SPDTL - EDTL).
+
+   If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in the
+   SCSI Response PDU as specified in [RFC3720].  The Residual Count MUST
+   be set to the numerical value of (EDTL - SPDTL).
+
+   Note that the Overflow and Underflow scenarios are independent of
+   Data-In and Data-Out.  Either scenario is logically possible in
+   either direction of data transfer.
+
+3.1.2.  SCSI REPORT LUNS and Residual Overflow
+
+   This section discusses the residual overflow issues citing the
+   example of the SCSI REPORT LUNS command.  Note however that there are
+   several SCSI commands (e.g., INQUIRY) with ALLOCATION LENGTH fields
+   following the same underlying rules.  The semantics in the rest of
+   the section apply to all such SCSI commands.
+
+
+
+
+
+Chadalapaka                 Standards Track                     [Page 7]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+   The specification of the SCSI REPORT LUNS command requires that the
+   SCSI target limit the amount of data transferred to a maximum size
+   (ALLOCATION LENGTH) provided by the initiator in the REPORT LUNS CDB.
+   If the Expected Data Transfer Length (EDTL) in the iSCSI header of
+   the SCSI Command PDU for a REPORT LUNS command is set to at least as
+   large as that ALLOCATION LENGTH, the SCSI layer truncation prevents
+   an iSCSI Residual Overflow from occurring.  A SCSI initiator can
+   detect that such truncation has occurred via other information at the
+   SCSI layer.  The rest of the section elaborates this required
+   behavior.
+
+   iSCSI uses the (O) bit (bit 5) in the Flags field of the SCSI
+   Response and the last SCSI Data-In PDUs to indicate that an iSCSI
+   target was unable to transfer all of the SCSI data for a command to
+   the initiator because the amount of data to be transferred exceeded
+   the EDTL in the corresponding SCSI Command PDU (see Section 10.4.1 of
+   [RFC3720]).
+
+   The SCSI REPORT LUNS command requests a target SCSI layer to return a
+   logical unit inventory (LUN list) to the initiator SCSI layer (see
+   Section 6.21 of SPC-3 [SPC3]).  The size of this LUN list may not be
+   known to the initiator SCSI layer when it issues the REPORT LUNS
+   command; to avoid transferring more LUN list data than the initiator
+   is prepared for, the REPORT LUNS CDB contains an ALLOCATION LENGTH
+   field to specify the maximum amount of data to be transferred to the
+   initiator for this command.  If the initiator SCSI layer has under-
+   estimated the number of logical units at the target, it is possible
+   that the complete logical unit inventory does not fit in the
+   specified ALLOCATION LENGTH.  In this situation, Section 4.3.3.6 in
+   [SPC3] requires that the target SCSI layer "shall terminate transfers
+   to the Data-In Buffer" when the number of bytes specified by the
+   ALLOCATION LENGTH field have been transferred.
+
+   Therefore, in response to a REPORT LUNS command, the SCSI layer at
+   the target presents at most ALLOCATION LENGTH bytes of data (logical
+   unit inventory) to iSCSI for transfer to the initiator.  For a REPORT
+   LUNS command, if the iSCSI EDTL is at least as large as the
+   ALLOCATION LENGTH, the SCSI truncation ensures that the EDTL will
+   accommodate all of the data to be transferred.  If all of the logical
+   unit inventory data presented to the iSCSI layer -- i.e., the data
+   remaining after any SCSI truncation -- is transferred to the
+   initiator by the iSCSI layer, an iSCSI Residual Overflow has not
+   occurred and the iSCSI (O) bit MUST NOT be set in the SCSI Response
+   or final SCSI Data-Out PDU.  This is not a new requirement but is
+   already required by the combination of [RFC3720] with the
+   specification of the REPORT LUNS command in [SPC3].  However, if the
+   iSCSI EDTL is larger than the ALLOCATION LENGTH in this scenario,
+   note that the iSCSI Underflow MUST be signaled in the SCSI Response
+
+
+
+Chadalapaka                 Standards Track                     [Page 8]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+   PDU.  An iSCSI Underflow MUST also be signaled when the iSCSI EDTL is
+   equal to the ALLOCATION LENGTH but the logical unit inventory data
+   presented to the iSCSI layer is smaller than the ALLOCATION LENGTH.
+
+   The LUN LIST LENGTH field in the logical unit inventory (the first
+   field in the inventory) is not affected by truncation of the
+   inventory to fit in ALLOCATION LENGTH; this enables a SCSI initiator
+   to determine that the received inventory is incomplete by noticing
+   that the LUN LIST LENGTH in the inventory is larger than the
+   ALLOCATION LENGTH that was sent in the REPORT LUNS CDB.  A common
+   initiator behavior in this situation is to re-issue the REPORT LUNS
+   command with a larger ALLOCATION LENGTH.
+
+3.2.  R2T Ordering
+
+   Section 10.8 in [RFC3720] says the following:
+
+      The target may send several R2T PDUs.  It, therefore, can have a
+      number of pending data transfers.  The number of outstanding R2T
+      PDUs is limited by the value of the negotiated key
+      MaxOutstandingR2T.  Within a connection, outstanding R2Ts MUST be
+      fulfilled by the initiator in the order in which they were
+      received.
+
+   The quoted [RFC3720] text was unclear on the scope of applicability
+   -- either per task, or across all tasks on a connection -- and may be
+   interpreted as either.  This section is intended to clarify that the
+   scope of applicability of the quoted text is a task.  No R2T ordering
+   relationship -- either in generation at the target or in fulfilling
+   at the initiator -- across tasks is implied.  That is, outstanding
+   R2Ts within a task MUST be fulfilled by the initiator in the order in
+   which they were received on a connection.
+
+3.3.  Model Assumptions for Response Ordering
+
+   Whenever an iSCSI session is composed of multiple connections, the
+   Response PDUs (task responses or TMF responses) originating in the
+   target SCSI layer are distributed onto the multiple connections by
+   the target iSCSI layer according to iSCSI connection allegiance
+   rules.  This process generally may not preserve the ordering of the
+   responses by the time they are delivered to the initiator SCSI layer.
+   Since ordering is not expected across SCSI responses anyway, this
+   approach works fine in the general case.  However, to address the
+   special cases where some ordering is desired by the SCSI layer, the
+   following "Response Fence" semantics are defined with respect to
+   handling SCSI response messages as they are handed off from the SCSI
+   protocol layer to the iSCSI layer.
+
+
+
+
+Chadalapaka                 Standards Track                     [Page 9]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+3.3.1.  Model Description
+
+   The target SCSI protocol layer hands off the SCSI response messages
+   to the target iSCSI layer by invoking the "Send Command Complete"
+   protocol data service ([SAM2], clause 5.4.2) and "Task Management
+   Function Executed" ([SAM2], clause 6.9) service.  On receiving the
+   SCSI response message, the iSCSI layer exhibits the Response Fence
+   behavior for certain SCSI response messages (Section 3.3.3 describes
+   the specific instances where the semantics must be realized).
+   Whenever the Response Fence behavior is required for a SCSI response
+   message, the target iSCSI layer MUST ensure that the following
+   conditions are met in delivering the response message to the
+   initiator iSCSI layer:
+
+   (1) Response with Response Fence MUST be delivered chronologically
+       after all the "preceding" responses on the I_T_L nexus, if the
+       preceding responses are delivered at all, to the initiator iSCSI
+       layer.
+
+   (2) Response with Response Fence MUST be delivered chronologically
+       prior to all the "following" responses on the I_T_L nexus.
+
+   The "preceding" and "following" notions refer to the order of handoff
+   of a response message from the target SCSI protocol layer to the
+   target iSCSI layer.
+
+3.3.2.  iSCSI Semantics with the Interface Model
+
+   Whenever the TaskReporting key (Section 9.1) is negotiated to
+   ResponseFence or FastAbort for an iSCSI session and the Response
+   Fence behavior is required for a SCSI response message, the target
+   iSCSI layer MUST perform the actions described in this section for
+   that session.
+
+      a) If it is a single-connection session, no special processing is
+         required.  The standard SCSI Response PDU build and dispatch
+         process happens.
+
+      b) If it is a multi-connection session, the target iSCSI layer
+         takes note of the last-sent and unacknowledged StatSN on each
+         of the connections in the iSCSI session, and waits for an
+         acknowledgement (NOP-In PDUs MAY be used to solicit
+         acknowledgements as needed in order to accelerate this process)
+         of each such StatSN to clear the fence.  The SCSI response
+         requiring Response Fence behavior MUST NOT be sent to the
+         initiator before acknowledgements are received for each of the
+         unacknowledged StatSNs.
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 10]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+      c) The target iSCSI layer must wait for an acknowledgement of the
+         SCSI Response PDU that carried the SCSI response requiring the
+         Response Fence behavior.  The fence MUST be considered cleared
+         only after receiving the acknowledgement.
+
+      d) All further status processing for the LU is resumed only after
+         clearing the fence.  If any new responses for the I_T_L nexus
+         are received from the SCSI layer before the fence is cleared,
+         those Response PDUs MUST be held and queued at the iSCSI layer
+         until the fence is cleared.
+
+3.3.3.  Current List of Fenced Response Use Cases
+
+   This section lists the fenced response use cases that iSCSI
+   implementations MUST comply with.  However, this is not an exhaustive
+   enumeration.  It is expected that as SCSI protocol specifications
+   evolve, the specifications will specify when response fencing is
+   required on a case-by-case basis.
+
+   Whenever the TaskReporting key (Section 9.1) is negotiated to
+   ResponseFence or FastAbort for an iSCSI session, the target iSCSI
+   layer MUST assume that the Response Fence is required for the
+   following SCSI completion messages:
+
+      1. The first completion message carrying the UA after the multi-
+         task abort on issuing and third-party sessions.  See Section
+         4.1.1 for related TMF discussion.
+
+      2. The TMF Response carrying the multi-task TMF Response on the
+         issuing session.
+
+      3. The completion message indicating ACA establishment on the
+         issuing session.
+
+      4. The first completion message carrying the ACA ACTIVE status
+         after ACA establishment on issuing and third-party sessions.
+
+      5. The TMF Response carrying the Clear ACA response on the issuing
+         session.
+
+      6. The response to a PERSISTENT RESERVE OUT/PREEMPT AND ABORT
+         command.
+
+   Note: Due to the absence of ACA-related fencing requirements in
+   [RFC3720], initiator implementations SHOULD NOT use ACA on multi-
+   connection iSCSI sessions to targets complying only with [RFC3720].
+   Initiators that want to employ ACA on multi-connection iSCSI sessions
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 11]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+   SHOULD first assess response-fencing behavior via negotiating for
+   ResponseFence or FastAbort values for the TaskReporting (Section 9.1)
+   key.
+
+4.  Task Management
+
+4.1.  Requests Affecting Multiple Tasks
+
+   This section clarifies and updates the original text in Section
+   10.6.2 of [RFC3720].  The clarified semantics (Section 4.1.2) are a
+   superset of the protocol behavior required in the original text and
+   all iSCSI implementations MUST support the new behavior.  The updated
+   semantics (Section 4.1.3) on the other hand are mandatory only when
+   the new key TaskReporting (Section 9.1) is negotiated to "FastAbort".
+
+4.1.1.  Scope of Affected Tasks
+
+   This section defines the notion of "affected tasks" in multi-task
+   abort scenarios.  Scope definitions in this section apply to both the
+   clarified protocol behavior (Section 4.1.2) and the updated protocol
+   behavior (Section 4.1.3).
+
+      ABORT TASK SET: All outstanding tasks for the I_T_L nexus
+         identified by the LUN field in the ABORT TASK SET TMF Request
+         PDU.
+
+      CLEAR TASK SET: All outstanding tasks in the task set for the LU
+         identified by the LUN field in the CLEAR TASK SET TMF Request
+         PDU.  See [SPC3] for the definition of a "task set".
+
+      LOGICAL UNIT RESET: All outstanding tasks from all initiators for
+         the LU identified by the LUN field in the LOGICAL UNIT RESET
+         Request PDU.
+
+      TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks from
+         all initiators across all LUs to which the TMF-issuing session
+         has access on the SCSI target device hosting the iSCSI session.
+
+   Usage: An "ABORT TASK SET TMF Request PDU" in the preceding text is
+   an iSCSI TMF Request PDU with the "Function" field set to "ABORT TASK
+   SET" as defined in [RFC3720].  Similar usage is employed for other
+   scope descriptions.
+
+
+
+
+
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 12]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+4.1.2.  Clarified Multi-Task Abort Semantics
+
+   All iSCSI implementations MUST support the protocol behavior defined
+   in this section as the default behavior.  The execution of ABORT TASK
+   SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and
+   TARGET COLD RESET TMF Requests consists of the following sequence of
+   actions in the specified order on the specified party.
+
+   The initiator iSCSI layer:
+
+      a. MUST continue to respond to each TTT received for the affected
+         tasks.
+
+      b. SHOULD process any responses received for affected tasks in the
+         normal fashion.  This is acceptable because the responses are
+         guaranteed to have been sent prior to the TMF response.
+
+      c. SHOULD receive the TMF Response concluding all the tasks in the
+         set of affected tasks unless the initiator has done something
+         (e.g., LU reset, connection drop) that may prevent the TMF
+         Response from being sent or received.  The initiator MUST thus
+         conclude all affected tasks as part of this step in either
+         case, and MUST discard any TMF Response received after the
+         affected tasks are concluded.
+
+   The target iSCSI layer:
+
+      a. MUST wait for responses on currently valid target-transfer tags
+         of the affected tasks from the issuing initiator.  MAY wait for
+         responses on currently valid target-transfer tags of the
+         affected tasks from third-party initiators.
+
+      b. MUST wait (concurrent with the wait in Step a) for all commands
+         of the affected tasks to be received based on the CmdSN
+         ordering.  SHOULD NOT wait for new commands on third-party
+         affected sessions -- only the instantiated tasks have to be
+         considered for the purpose of determining the affected tasks.
+         In the case of target-scoped requests (i.e., TARGET WARM RESET
+         and TARGET COLD RESET), all of the commands that are not yet
+         received on the issuing session in the command stream however
+         can be considered to have been received with no command waiting
+         period -- i.e., the entire CmdSN space up to the CmdSN of the
+         task management function can be "plugged".
+
+      c. MUST propagate the TMF request to and receive the response from
+         the target SCSI layer.
+
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 13]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+      d. MUST provide the Response Fence behavior for the TMF Response
+         on the issuing session as specified in Section 3.3.2.
+
+      e. MUST provide the Response Fence behavior on the first post-TMF
+         Response on third-party sessions as specified in Section 3.3.2.
+         If some tasks originate from non-iSCSI I_T_L nexuses, then the
+         means by which the target ensures that all affected tasks have
+         returned their status to the initiator are defined by the
+         specific non-iSCSI transport protocol(s).
+
+   Technically, the TMF servicing is complete in Step d.  Data transfers
+   corresponding to terminated tasks may however still be in progress on
+   third-party iSCSI sessions even at the end of Step e.  The TMF
+   Response MUST NOT be sent by the target iSCSI layer before the end of
+   Step d, and MAY be sent at the end of Step d despite these
+   outstanding data transfers until after Step e.
+
+4.1.3.  Updated Multi-Task Abort Semantics
+
+   Protocol behavior defined in this section MUST be implemented by all
+   iSCSI implementations complying with this document.  Protocol
+   behavior defined in this section MUST be exhibited by iSCSI
+   implementations on an iSCSI session when they negotiate the
+   TaskReporting (Section 9.1) key to "FastAbort" on that session.  The
+   execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET,
+   TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the
+   following sequence of actions in the specified order on the specified
+   party.
+
+   The initiator iSCSI layer:
+
+      a. MUST NOT send any more Data-Out PDUs for affected tasks on the
+         issuing connection of the issuing iSCSI session once the TMF is
+         sent to the target.
+
+      b. SHOULD process any responses received for affected tasks in the
+         normal fashion.  This is acceptable because the responses are
+         guaranteed to have been sent prior to the TMF response.
+
+      c. MUST respond to each Async Message PDU with AsyncEvent=5 as
+         defined in Section 8.1.
+
+      d. MUST treat the TMF response as terminating all affected tasks
+         for which responses have not been received, and MUST discard
+         any responses for affected tasks received after the TMF
+         response is passed to the SCSI layer (although the semantics
+
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 14]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+         defined in this section ensure that such an out-of-order
+         scenario will never happen with a compliant target
+         implementation).
+
+   The target iSCSI layer:
+
+      a. MUST wait for all commands of the affected tasks to be received
+         based on the CmdSN ordering on the issuing session.  SHOULD NOT
+         wait for new commands on third-party affected sessions -- only
+         the instantiated tasks have to be considered for the purpose of
+         determining the affected tasks.  In the case of target-scoped
+         requests (i.e., TARGET WARM RESET and TARGET COLD RESET), all
+         the commands that are not yet received on the issuing session
+         in the command stream can be considered to have been received
+         with no command waiting period -- i.e., the entire CmdSN space
+         up to the CmdSN of the task management function can be
+         "plugged".
+
+      b. MUST propagate the TMF request to and receive the response from
+         the target SCSI layer.
+
+      c. MUST leave all active "affected TTTs" (i.e., active TTTs
+         associated with affected tasks) valid.
+
+      d. MUST send an Asynchronous Message PDU with AsyncEvent=5
+         (Section 8.1) on:
+
+          i) each connection of each third-party session to which at
+             least one affected task is allegiant if
+             TaskReporting=FastAbort is operational on that third-party
+             session, and
+
+         ii) each connection except the issuing connection of the
+             issuing session that has at least one allegiant affected
+             task.
+
+      If there are multiple affected LUs (say, due to a target reset),
+      then one Async Message PDU MUST be sent for each such LU on each
+      connection that has at least one allegiant affected task.  The LUN
+      field in the Asynchronous Message PDU MUST be set to match the LUN
+      for each such LU.
+
+      e. MUST address the Response Fence flag on the TMF Response on the
+         issuing session as defined in Section 3.3.2.
+
+      f. MUST address the Response Fence flag on the first post-TMF
+         Response on third-party sessions as defined in Section 3.3.2.
+         If some tasks originate from non-iSCSI I_T_L nexuses, then the
+
+
+
+Chadalapaka                 Standards Track                    [Page 15]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+         means by which the target ensures that all affected tasks have
+         returned their status to the initiator are defined by the
+         specific non-iSCSI transport protocol(s).
+
+      g. MUST free up the affected TTTs (and STags, if applicable) and
+         the corresponding buffers, if any, once it receives each
+         associated NOP-Out acknowledgement that the initiator generated
+         in response to each Async Message.
+
+   Technically, the TMF servicing is complete in Step e.  Data transfers
+   corresponding to terminated tasks may however still be in progress
+   even at the end of Step f.  A TMF Response MUST NOT be sent by the
+   target iSCSI layer before the end of Step e, and MAY be sent at the
+   end of Step e despite these outstanding Data transfers until Step g.
+   Step g specifies an event to free up any such resources that may have
+   been reserved to support outstanding data transfers.
+
+4.1.3.1.  Clearing Effects Update
+
+   Appendix F.1 of [RFC3720] specifies the clearing effects of target
+   and LU resets on "Incomplete TTTs" as "Y".  This meant that a target
+   warm reset or a target cold reset or an LU reset would clear the
+   active TTTs upon completion.  However, the TaskReporting=FastAbort
+   (Section 9.1) semantics defined by this section do not guarantee that
+   the active TTTs are cleared by the end of the reset operations.  In
+   fact, the new semantics are designed to allow clearing the TTTs in a
+   "lazy" fashion after the TMF Response is delivered.  Thus, when
+   TaskReporting=FastAbort is operational on a session, the clearing
+   effects of reset operations on "Incomplete TTTs" is "N".
+
+4.1.4.  Affected Tasks Shared across RFC 3720 and FastAbort Sessions
+
+   If an iSCSI target implementation is capable of supporting
+   TaskReporting=FastAbort functionality (Section 9.1), it may end up in
+   a situation where some sessions have TaskReporting=RFC3720
+   operational (RFC 3720 sessions) while some other sessions have
+   TaskReporting=FastAbort operational (FastAbort sessions) even while
+   accessing a shared set of affected tasks (Section 4.1.1).
+
+   If the issuing session is an RFC 3720 session, the iSCSI target
+   implementation is FastAbort-capable, and the third-party affected
+   session is a FastAbort session, the following behavior SHOULD be
+   exhibited by the iSCSI target layer:
+
+      a. Between Steps c and d of the target behavior in Section 4.1.2,
+         send an Asynchronous Message PDU with AsyncEvent=5 (Section
+         8.1) on each connection of each third-party session to which at
+         least one affected task is allegiant.  If there are multiple
+
+
+
+Chadalapaka                 Standards Track                    [Page 16]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+         affected LUs, then send one Async Message PDU for each such LU
+         on each connection that has at least one allegiant affected
+         task.  When sent, the LUN field in the Asynchronous Message PDU
+         MUST be set to match the LUN for each such LU.
+
+      b. After Step e of the target behavior in Section 4.1.2, free up
+         the affected TTTs (and STags, if applicable) and the
+         corresponding buffers, if any, once each associated NOP-Out
+         acknowledgement is received that the third-party initiator
+         generated in response to each Async Message sent in Step a.
+
+   If the issuing session is a FastAbort session, the iSCSI target
+   implementation is FastAbort-capable, and the third-party affected
+   session is an RFC 3720 session, the following behavior MUST be
+   exhibited by the iSCSI target layer: Asynchronous Message PDUs MUST
+   NOT be sent on the third-party session to prompt the FastAbort
+   behavior.
+
+   If the third-party affected session is a FastAbort session and the
+   issuing session is a FastAbort session, the initiator in the third-
+   party role MUST respond to each Async Message PDU with AsyncEvent=5
+   as defined in Section 8.1.  Note that an initiator MAY thus receive
+   these Async Messages on a third-party affected session even if the
+   session is a single-connection session.
+
+4.1.5.  Implementation Considerations
+
+   Both in clarified semantics (Section 4.1.2) and updated semantics
+   (Section 4.1.3), there may be outstanding data transfers even after
+   the TMF completion is reported on the issuing session.  In the case
+   of iSCSI/iSER [iSER], these would be tagged data transfers for STags
+   not owned by any active tasks.  Whether or not real buffers support
+   these data transfers is implementation-dependent.  However, the data
+   transfers logically MUST be silently discarded by the target iSCSI
+   layer in all cases.  A target MAY, on an implementation-defined
+   internal timeout, also choose to drop the connections on which it did
+   not receive the expected Data-Out sequences (Section 4.1.2) or NOP-
+   Out acknowledgements (Section 4.1.3) so as to reclaim the associated
+   buffer, STag, and TTT resources as appropriate.
+
+4.1.6.  Rationale behind the New Semantics
+
+   There are fundamentally three basic objectives behind the semantics
+   specified in Sections 4.1.2 and 4.1.3.
+
+      1. Maintaining an ordered command flow I_T nexus abstraction to
+         the target SCSI layer even with multi-connection sessions.
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 17]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+         o  Target iSCSI processing of a TMF request must maintain the
+            single flow illusion.  Target behavior in Step b of Section
+            4.1.2 and Step a of Section 4.1.3 correspond to this
+            objective.
+
+      2. Maintaining a single ordered response flow I_T nexus
+         abstraction to the initiator SCSI layer even with multi-
+         connection sessions when one response (i.e., TMF response)
+         could imply the status of other unfinished tasks from the
+         initiator's perspective.
+
+         o  The target must ensure that the initiator does not see "old"
+            task responses (that were placed on the wire chronologically
+            earlier than the TMF Response) after seeing the TMF
+            response.  The target behavior in Step d of Section 4.1.2
+            and Step e of Section 4.1.3 correspond to this objective.
+
+         o  Whenever the result of a TMF action is visible across
+            multiple I_T_L nexuses, [SAM2] requires the SCSI device
+            server to trigger a UA on each of the other I_T_L nexuses.
+            Once an initiator is notified of such an UA, the application
+            client on the receiving initiator is required to clear its
+            task state (clause 5.5 in [SAM2]) for the affected tasks.
+            It would thus be inappropriate to deliver a SCSI Response
+            for a task after the task state is cleared on the initiator,
+            i.e., after the UA is notified.  The UA notification
+            contained in the first SCSI Response PDU on each affected
+            Third-party I_T_L nexus after the TMF action thus MUST NOT
+            pass the affected task responses on any of the iSCSI
+            sessions accessing the LU.  The target behavior in Step e of
+            Section 4.1.2 and Step f of Section 4.1.3 correspond to this
+            objective.
+
+      3. Draining all active TTTs corresponding to affected tasks in a
+         deterministic fashion.
+
+         o  Data-Out PDUs with stale TTTs arriving after the tasks are
+            terminated can create a buffer management problem even for
+            traditional iSCSI implementations, and is fatal for the
+            connection for iSCSI/iSER implementations.  Either the
+            termination of affected tasks should be postponed until the
+            TTTs are retired (as in Step a of Section 4.1.2), or the
+            TTTs and the buffers should stay allocated beyond task
+            termination to be deterministically freed up later (as in
+            Steps c and g of Section 4.1.3).
+
+   The only other notable optimization is the plugging.  If all tasks on
+   an I_T nexus will be aborted anyway (as with a target reset), there
+
+
+
+Chadalapaka                 Standards Track                    [Page 18]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+   is no need to wait to receive all commands to plug the CmdSN holes.
+   The target iSCSI layer can simply plug all missing CmdSN slots and
+   move on with TMF processing.  The first objective (maintaining a
+   single ordered command flow) is still met with this optimization
+   because the target SCSI layer only sees ordered commands.
+
+5.  Discovery Semantics
+
+5.1.  Error Recovery for Discovery Sessions
+
+   The negotiation of the key ErrorRecoveryLevel is not required for
+   Discovery sessions -- i.e., for sessions that negotiated
+   "SessionType=Discovery" -- because the default value of 0 is
+   necessary and sufficient for Discovery sessions.  It is however
+   possible that some legacy iSCSI implementations might attempt to
+   negotiate the ErrorRecoveryLevel key on Discovery sessions.  When
+   such a negotiation attempt is made by the remote side, a compliant
+   iSCSI implementation MUST propose a value of 0 (zero) in response.
+   The operational ErrorRecoveryLevel for Discovery sessions thus MUST
+   be 0.  This naturally follows from the functionality constraints that
+   [RFC3720] imposes on Discovery sessions.
+
+5.2.  Reinstatement Semantics of Discovery Sessions
+
+   Discovery sessions are intended to be relatively short-lived.
+   Initiators are not expected to establish multiple Discovery sessions
+   to the same iSCSI Network Portal (see [RFC3720]).  An initiator may
+   use the same iSCSI Initiator Name and ISID when establishing
+   different unique sessions with different targets and/or different
+   portal groups.  This behavior is discussed in Section 9.1.1 of
+   [RFC3720] and is, in fact, encouraged as conservative reuse of ISIDs.
+   The ISID RULE in [RFC3720] states that there must not be more than
+   one session with a matching 4-tuple: <InitiatorName, ISID,
+   TargetName, TargetPortalGroupTag>.  While the spirit of the ISID RULE
+   applies to Discovery sessions the same as it does for Normal
+   sessions, note that some Discovery sessions differ from the Normal
+   sessions in two important aspects:
+
+      Because [RFC3720] allows a Discovery session to be established
+      without specifying a TargetName key in the Login Request PDU (let
+      us call such a session an "Unnamed" Discovery session), there is
+      no Target Node context to enforce the ISID RULE.
+
+      Portal Groups are defined only in the context of a Target Node.
+      When the TargetName key is NULL-valued (i.e., not specified), the
+      TargetPortalGroupTag thus cannot be ascertained to enforce the
+      ISID RULE.
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 19]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+   The following sections describe the two scenarios -- Named Discovery
+   sessions and Unnamed Discovery sessions -- separately.
+
+5.2.1.  Unnamed Discovery Sessions
+
+   For Unnamed Discovery sessions, neither the TargetName nor the
+   TargetPortalGroupTag is available to the targets in order to enforce
+   the ISID RULE.  So the following rule applies.
+
+   UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the
+   following 4-tuple for Unnamed Discovery sessions: <InitiatorName,
+   ISID, NULL, TargetAddress>.  The following semantics are implied by
+   this uniqueness requirement.
+
+   Targets SHOULD allow concurrent establishment of one Discovery
+   session with each of its Network Portals by the same initiator port
+   with a given iSCSI Node Name and an ISID.  Each of the concurrent
+   Discovery sessions, if established by the same initiator port to
+   other Network Portals, MUST be treated as independent sessions --
+   i.e., one session MUST NOT reinstate the other.
+
+   A new Unnamed Discovery session that has a matching <InitiatorName,
+   ISID, NULL, TargetAddress> to an existing Discovery session MUST
+   reinstate the existing Unnamed Discovery session.  Note thus that
+   only an Unnamed Discovery session may reinstate an Unnamed Discovery
+   session.
+
+5.2.2.  Named Discovery Sessions
+
+   For a Named Discovery session, the TargetName key is specified by the
+   initiator and thus the target can unambiguously ascertain the
+   TargetPortalGroupTag as well.  Since all the four elements of the 4-
+   tuple are known, the ISID RULE MUST be enforced by targets with no
+   changes from [RFC3720] semantics.  A new session with a matching
+   <InitiatorName, ISID, TargetName, TargetPortalGroupTag> thus will
+   reinstate an existing session.  Note in this case that any new iSCSI
+   session (Discovery or Normal) with the matching 4-tuple may reinstate
+   an existing Named Discovery iSCSI session.
+
+5.3.  Target PDUs during Discovery
+
+   Targets SHOULD NOT send any responses other than a Text Response and
+   Logout Response on a Discovery session, once in Full Feature Phase.
+
+   Implementation Note: A target may simply drop the connection in a
+   Discovery session when it would have requested a Logout via an Async
+   Message on Normal sessions.
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 20]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+6.  Negotiation and Others
+
+6.1.  TPGT Values
+
+   [SAM2] and [SAM3] specifications incorrectly note in their
+   informative text that TPGT value should be non-zero, although
+   [RFC3720] allows the value of zero for TPGT.  This section is to
+   clarify that a zero value is expressly allowed as a legal value for
+   TPGT.  This discrepancy currently stands corrected in [SAM4].
+
+6.2.  SessionType Negotiation
+
+   During the Login Phase, the SessionType key is offered by the
+   initiator to choose the type of session it wants to create with the
+   target.  The target may accept or reject the offer.  Depending on the
+   type of the session, a target may decide on resources to allocate and
+   the security to enforce, etc. for the session.  If the SessionType
+   key is thus going to be offered as "Discovery", it SHOULD be offered
+   in the initial Login request by the initiator.
+
+6.3.  Understanding NotUnderstood
+
+   [RFC3720] defines NotUnderstood as a valid answer during a
+   negotiation text key exchange between two iSCSI nodes.  NotUnderstood
+   has the reserved meaning that the sending side did not understand the
+   proposed key semantics.  This section seeks to clarify that
+   NotUnderstood is a valid answer for both declarative and negotiated
+   keys.  The general iSCSI philosophy is that comprehension precedes
+   processing for any iSCSI key.  A proposer of an iSCSI key, negotiated
+   or declarative, in a text key exchange MUST thus be able to properly
+   handle a NotUnderstood response.
+
+   The proper way to handle a NotUnderstood response depends on where
+   the key is specified and whether the key is declarative vs.
+   negotiated.  All keys defined in [RFC3720] MUST be supported by all
+   compliant implementations; a NotUnderstood answer on any of the
+   [RFC3720] keys therefore MUST be considered a protocol error and
+   handled accordingly.  For all other later keys, a NotUnderstood
+   answer concludes the negotiation for a negotiated key whereas for a
+   declarative key, a NotUnderstood answer simply informs the declarer
+   of a lack of comprehension by the receiver.
+
+   In either case, a NotUnderstood answer always requires that the
+   protocol behavior associated with that key not be used within the
+   scope of the key (connection/session) by either side.
+
+
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 21]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+6.4.  Outstanding Negotiation Exchanges
+
+   There was some uncertainty around the number of outstanding Login
+   Response PDUs on a connection.  [RFC3720] offers the analogy of SCSI
+   linked commands to Login and Text negotiations in Sections 5.3 and
+   10.10.3, respectively, but does not make it fully explicit.  This
+   section is to offer a clarification in this regard.
+
+   There MUST NOT be more than one outstanding Login Request, Login
+   Response, Text Request, or Text Response PDU on an iSCSI connection.
+   An outstanding PDU in this context is one that has not been
+   acknowledged by the remote iSCSI side.
+
+7.  iSCSI Error Handling and Recovery
+
+7.1.  ITT
+
+   An ITT value of 0xffffffff is reserved and MUST NOT be assigned for a
+   task by the initiator.  The only instance in which it may be seen on
+   the wire is in a target-initiated NOP-In PDU (and in the initiator
+   response to that PDU, if necessary).  Section 10.19 in [RFC3720]
+   mentions this in passing but is noted here again to make it obvious
+   since the semantics apply to the initiators in general.
+
+7.2.  Format Errors
+
+   Section 6.6 of [RFC3720] discusses format error handling.  This
+   section elaborates on the "inconsistent" PDU field contents noted in
+   [RFC3720].
+
+   All initiator-detected PDU construction errors MUST be considered as
+   format errors.  Some examples of such errors are:
+
+      -  NOP-In with a valid TTT but an invalid LUN
+
+      -  NOP-In with a valid ITT (i.e., a NOP-In response) and also a
+         valid TTT
+
+      -  SCSI Response PDU with Status=CHECK CONDITION, but
+         DataSegmentLength = 0
+
+7.3.  Digest Errors
+
+   Section 6.7 of [RFC3720] discusses digest error handling.  It states
+   that "No further action is necessary for initiators if the discarded
+   PDU is an unsolicited PDU (e.g., Async, Reject)" on detecting a
+   payload digest error.  This is incorrect.
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 22]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+   An Asynchronous Message PDU or a Reject PDU carries the next StatSN
+   value on an iSCSI connection, advancing the StatSN.  When an
+   initiator discards one of these PDUs due to a payload digest error,
+   the entire PDU including the header MUST be discarded.  Consequently,
+   the initiator MUST treat the exception like a loss of any other
+   solicited response PDU -- i.e., it MUST use one of the following
+   options noted in [RFC3720]:
+
+      a) Request PDU retransmission with a status SNACK.
+
+      b) Logout the connection for recovery and continue the tasks on a
+         different connection instance.
+
+      c) Logout to close the connection (abort all the commands
+         associated with the connection).
+
+7.4.  Message Error Checking
+
+   There has been some uncertainty on the extent to which incoming
+   messages have to be checked for protocol errors, beyond what is
+   strictly required for processing the inbound message.  This section
+   addresses this question.
+
+   Unless [RFC3720] or this document requires it, an iSCSI
+   implementation is not required to do an exhaustive protocol
+   conformance check on an incoming iSCSI PDU.  The iSCSI implementation
+   especially is not required to double-check the remote iSCSI
+   implementation's conformance to protocol requirements.
+
+8.  iSCSI PDUs
+
+8.1.  Asynchronous Message
+
+   This section defines additional semantics for the Asynchronous
+   Message PDU defined in Section 10.9 of [RFC3720] using the same
+   conventions.
+
+   The following new legal value for the AsyncEvent is defined:
+
+   5: all active tasks for LU with a matching LUN field in the Async
+   Message PDU are being terminated.
+
+   The receiving initiator iSCSI layer MUST respond to this Message by
+   taking the following steps in order.
+
+       i) Stop Data-Out transfers on that connection for all active TTTs
+          for the affected LUN quoted in the Async Message PDU.
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 23]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+      ii) Acknowledge the StatSN of the Async Message PDU via a NOP-Out
+          PDU with ITT=0xffffffff (i.e., non-ping flavor), while copying
+          the LUN field from the Async Message to NOP-Out.
+
+   The new AsyncEvent defined in this section however MUST NOT be used
+   on an iSCSI session unless the new TaskReporting text key defined in
+   Section 9.1 was negotiated to FastAbort on the session.
+
+8.2.  Reject
+
+   Section 10.17.1 of [RFC3720] specifies the Reject reason code of 0x0b
+   with an explanation of "Negotiation Reset".  At this point, we do not
+   see any legitimate iSCSI protocol use case for using this reason
+   code.  Thus, reason code 0x0b MUST be considered as deprecated and
+   MUST NOT be sent by implementations that comply with the requirements
+   of this document.  An implementation receiving reason code 0x0b MUST
+   treat it as a negotiation failure that terminates the Login Phase and
+   the TCP connection, as specified in Section 6.10 of [RFC3720].
+
+   Section 5.4 of [RFC3720] states:
+
+      Neither the initiator nor the target should attempt to declare or
+      negotiate a parameter more than once during any negotiation
+      sequence without an intervening operational parameter negotiation
+      reset, except for responses to specific keys that explicitly allow
+      repeated key declarations (e.g., TargetAddress).
+
+   The deprecation of reason code 0x0b eliminates the possibility of an
+   operational parameter negotiation reset, causing the phrase "without
+   an intervening operational parameter negotiation reset" in [RFC3720]
+   to refer to an impossible event.  The quoted phrase SHOULD be ignored
+   by receivers that handle reason code 0x0b in the manner specified in
+   this section.
+
+9.  Login/Text Operational Text Keys
+
+   This section follows the same conventions as Section 12 of [RFC3720].
+
+9.1.  TaskReporting
+
+   Use: LO
+   Senders: Initiator and Target
+   Scope: SW
+
+   Irrelevant when: SessionType=Discovery
+   TaskReporting=<list-of-values>
+
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 24]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+   Default is RFC3720.
+   Result function is AND.
+
+   This key is used to negotiate the task completion reporting semantics
+   from the SCSI target.  The following table describes the semantics
+   that an iSCSI target MUST support for respective negotiated key
+   values.  Whenever this key is negotiated, at least the RFC3720 and
+   ResponseFence values MUST be offered as options by the negotiation
+   originator.
+
+   +--------------+------------------------------------------+
+   | Name         |             Description                  |
+   +--------------+------------------------------------------+
+   | RFC3720      | RFC 3720-compliant semantics.  Response  |
+   |              | fencing is not guaranteed and fast       |
+   |              | completion of multi-task aborting is not |
+   |              | supported                                |
+   +--------------+------------------------------------------+
+   | ResponseFence| Response Fence (Section 3.3.1) semantics |
+   |              | MUST be supported in reporting task      |
+   |              | completions                              |
+   +--------------+------------------------------------------+
+   | FastAbort    | Updated fast multi-task abort semantics  |
+   |              | defined in Section 4.1.3 MUST be         |
+   |              | supported.  Support for Response Fence is|
+   |              | implied -- i.e., Section 3.3.1 semantics |
+   |              | MUST be supported as well                |
+   +--------------+------------------------------------------+
+
+   When TaskReporting is not negotiated to FastAbort, the [RFC3720] TMF
+   semantics as clarified in Section 4.1.2 MUST be used.
+
+10.  Security Considerations
+
+   This document does not introduce any new security considerations
+   other than those already noted in [RFC3720].  Consequently, all the
+   iSCSI-related security text in [RFC3723] is also directly applicable
+   to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 25]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+11.  IANA Considerations
+
+11.1.  iSCSI-Related IANA Registries
+
+   This document creates the following iSCSI-related registries for IANA
+   to manage.
+
+      1. iSCSI Opcodes
+
+      2. iSCSI Login/Text Keys
+
+      3. iSCSI Asynchronous Events
+
+      4. iSCSI Task Management Function Codes
+
+      5. iSCSI Login Response Status Codes
+
+      6. iSCSI Reject Reason Codes
+
+      7. iSER Opcodes
+
+   Each of the following sections describes a registry, its sub-
+   registries if any, and their administration policies in more detail.
+   IANA has registered what this document calls the main "registries" as
+   sub-registries of a larger iSCSI registry.  However, wherever
+   registry-to-sub-registry relationships are specified by this
+   document, they have been preserved intact.
+
+   [RFC3720] specifies three iSCSI-related registries -- extended key,
+   authentication methods, and digests.  This document recommends that
+   these registries be published together with the registries defined by
+   this document.  Further, this document recommends that the three
+   [RFC3720] registries be listed in between items 6 and 7 in the
+   registry list above.
+
+11.2.  iSCSI Opcodes
+
+   Name of the registry: "iSCSI Opcodes"
+
+   Namespace details: Numerical values that can fit in one octet with
+   the most significant two bits (bits 0 and 1) already designated by
+   [RFC3720], bit 0 being reserved and bit 1 for immediate delivery.
+   Bit 2 is designated to identify the originator of the opcode.  Bit 2
+   = 0 for initiator and Bit 2 = 1 for target.
+
+
+
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 26]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+   Information that must be provided to assign a new value: An IESG-
+   approved standards-track specification defining the semantics and
+   interoperability requirements of the proposed new value and the
+   fields to be recorded in the registry.
+
+   Allocation request guidance to requesters:
+
+      1) If the initiator opcode and target opcode used to identify the
+         request and response of a new type of protocol operation are
+         requested, assign the same lower five bits (i.e., Bit 3 through
+         Bit 7) for both opcodes, e.g., 0x13 and 0x33.
+
+      2) If only the initiator opcode or target opcode is requested to
+         identify a one-way protocol message (i.e., request without a
+         response or a "response" without a request), assign an unused
+         number from the appropriate category (i.e., Bit 2 set to 0 or 1
+         for initiator category or target category) and add the other
+         pair member (i.e., same opcode with Bit 2 set to 1 or 0,
+         respectively) to "no opcode pair is available" list.
+
+      3) If there are no other opcodes available in the appropriate
+         "Reserved to IANA" list to assign on a request for a new opcode
+         except the reserved opcodes in the "no opcode pair is
+         available" list, allocate the opcode from the appropriate
+         category (initiator or target) of the "no opcode pair is
+         available" list.
+
+   Fields to record in the registry: Assigned value, Who can originate
+   (Initiator or Target), Operation Name, and its associated RFC
+   reference.
+
+   Initial registry contents:
+
+   0x00, Initiator, NOP-Out, [RFC3720]
+
+   0x01, Initiator, SCSI Command, [RFC3720]
+
+   0x02, Initiator, SCSI Task Management function request, [RFC3720]
+
+   0x03, Initiator, Login Request, [RFC3720]
+
+   0x04, Initiator, Text Request, [RFC3720]
+
+   0x05, Initiator, SCSI Data-Out, [RFC3720]
+
+   0x06, Initiator, Logout Request, [RFC3720]
+
+   0x10, Initiator, SNACK Request, [RFC3720]
+
+
+
+Chadalapaka                 Standards Track                    [Page 27]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+   0x1c-0x1e, Initiator, Vendor specific codes, [RFC3720]
+
+   0x20, Target, NOP-In, [RFC3720]
+
+   0x21, Target, SCSI Response, [RFC3720]
+
+   0x22, Target, SCSI Task Management function response, [RFC3720]
+
+   0x23, Target, Login Response, [RFC3720]
+
+   0x24, Target, Text Response, [RFC3720]
+
+   0x25, Target, SCSI Data-In, [RFC3720]
+
+   0x26, Target, Logout Response, [RFC3720]
+
+   0x31, Target, Ready To Transfer (R2T), [RFC3720]
+
+   0x32, Target, Asynchronous Message, [RFC3720]
+
+   0x3c-0x3e, Target, Vendor specific codes, [RFC3720]
+
+   0x3f, Target, Reject, [RFC3720]
+
+   Reserved to IANA:
+       0x07-0x0f, 0x13-0x1b (initiator codes)
+       0x27-0x2f, 0x33-0x3b (target codes)
+
+   No opcode pair is available:
+       0x11, 0x12, 0x1f (initiator codes)
+       0x30 (target codes)
+
+   Allocation Policy:
+
+   Standards Action ([IANA]): This is required for defining the
+   semantics of the opcode.
+
+   Expert Review ([IANA]): This is required for selecting the specific
+   opcode(s) to allocate in order to ensure compliance with the earlier
+   "Allocation request guidance to requesters".
+
+11.3.  iSCSI Login/Text Keys
+
+   Name of the registry: "iSCSI Text Keys"
+
+   Namespace details: Key=value pairs with "Key" names in UTF-8 Unicode,
+   and the permissible "value" options for the "Key" are Key-dependent.
+   [RFC3720] defines the rules on key names and allowed values.
+
+
+
+Chadalapaka                 Standards Track                    [Page 28]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+   Information that must be provided to assign a new value: An IESG-
+   approved standards-track specification defining the semantics and
+   interoperability requirements of the proposed new Key per [RFC3720]
+   key specification template and the fields to be recorded in the
+   registry.
+
+   Assignment policy:
+
+   If the requested Key name is not already assigned and is roughly
+   representative of its proposed semantics, it may be assigned to the
+   requester.
+
+   Given the arbitrary nature of text strings, there is no maximum
+   reserved by IANA for assignment in this registry.
+
+   Fields to record in the registry: Assigned Key Name and its
+   associated RFC reference.
+
+   Initial registry contents:
+
+   AuthMethod, [RFC3720]
+
+   HeaderDigest, [RFC3720]
+
+   DataDigest, [RFC3720]
+
+   MaxConnections, [RFC3720]
+
+   SendTargets, [RFC3720]
+
+   TargetName, [RFC3720]
+
+   InitiatorName, [RFC3720]
+
+   TargetAlias, [RFC3720]
+
+   InitiatorAlias, [RFC3720]
+
+   TargetAddress, [RFC3720]
+
+   TargetPortalGroupTag, [RFC3720]
+
+   InitialR2T, [RFC3720]
+
+   ImmediateData, [RFC3720]
+
+   MaxRecvDataSegmentLength, [RFC3720]
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 29]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+   MaxBurstLength, [RFC3720]
+
+   FirstBurstLength, [RFC3720]
+
+   DefaultTime2Wait, [RFC3720]
+
+   DefaultTime2Retain, [RFC3720]
+
+   MaxOutstandingR2T, [RFC3720]
+
+   DataPDUInOrder, [RFC3720]
+
+   DataSequenceInOrder, [RFC3720]
+
+   ErrorRecoveryLevel, [RFC3720]
+
+   SessionType, [RFC3720]
+
+   RDMAExtensions, [iSER]
+
+   TargetRecvDataSegmentLength, [iSER]
+
+   InitiatorRecvDataSegmentLength, [iSER]
+
+   MaxOutstandingUnexpectedPDUs, [iSER]
+
+   TaskReporting, this document
+
+   Allocation Policy:
+
+   Standards Action ([IANA])
+
+11.4.  iSCSI Asynchronous Events
+
+   Name of the registry: "iSCSI Asynchronous Events"
+
+   Namespace details: Numerical values that can fit in one octet.
+
+   Information that must be provided to assign a new value: An IESG-
+   approved standards-track specification defining the semantics and
+   interoperability requirements of the proposed new Event and the
+   fields to be recorded in the registry.
+
+   Assignment policy:
+
+   If the requested value is not already assigned, it may be assigned to
+   the requester.
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 30]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+   6-247: range reserved by IANA for assignment in this registry.
+
+   Fields to record in the registry: Assigned Event number, Description
+   and its associated RFC reference.
+
+   Initial registry contents:
+
+   0, SCSI Async Event, [RFC3720]
+
+   1, Logout Request, [RFC3720]
+
+   2, Connection drop notification, [RFC3720]
+
+   3, Session drop notification, [RFC3720]
+
+   4, Negotiation Request, [RFC3720]
+
+   5, Task termination, this document
+
+   248-254, Vendor-unique, this document
+
+   255, Vendor-unique, [RFC3720]
+
+   Allocation Policy:
+
+   Standards Action ([IANA])
+
+11.5.  iSCSI Task Management Function Codes
+
+   Name of the registry: "iSCSI TMF Codes"
+
+   Namespace details: Numerical values that can fit in 7 bits.
+
+   Information that must be provided to assign a new value: An IESG-
+   approved standards-track specification defining the semantics and
+   interoperability requirements of the proposed new Code and the fields
+   to be recorded in the registry.
+
+   Assignment policy:
+
+   If the requested value is not already assigned, it may be assigned to
+   the requester.
+
+   9-127: range reserved by IANA for assignment in this registry.
+
+   Fields to record in the registry: Assigned Code, Description, and its
+   associated RFC reference.
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 31]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+   Initial registry contents:
+
+   1, ABORT TASK, [RFC3720]
+
+   2, ABORT TASK SET, [RFC3720]
+
+   3, CLEAR ACA, [RFC3720]
+
+   4, CLEAR TASK SET, [RFC3720]
+
+   5, LOGICAL UNIT RESET, [RFC3720]
+
+   6, TARGET WARM RESET, [RFC3720]
+
+   7, TARGET COLD RESET, [RFC3720]
+
+   8, TASK REASSIGN, [RFC3720]
+
+   Allocation Policy:
+
+   Standards Action ([IANA])
+
+11.6.  iSCSI Login Response Status Codes
+
+   Name of the registry: "iSCSI Login Response Status Codes"
+
+   Namespace details: Numerical values; Status-Class (one octet),
+   Status-Detail (one octet) for each possible value of Status-Class
+   except for Vendor-Unique Status-Class (0x0f).
+
+   Information that must be provided to assign a new value: An IESG-
+   approved specification defining the semantics and interoperability
+   requirements of the proposed new Code, its Status-Class affiliation
+   (only if a new Status-Detail value is being proposed for a Status-
+   Class), Status-Class definition (only if a new Status-Class is being
+   proposed), and the fields to be recorded in the registry.
+
+   Assignment policy:
+
+   If the requested value is not already assigned, it may be assigned to
+   the requester.
+
+   4-14 and 16-255: range reserved by IANA for assignment in this
+   registry.
+
+   Fields to record in the Status-Class main registry: Assigned Code,
+   Description, and its associated RFC reference.
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 32]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+   Fields to record in the Status-Detail sub-registries: Status-Class,
+   Assigned Code, Description, and its associated RFC reference.
+
+   Initial registry contents (Status-Class):
+
+   0x00, Success, [RFC3720]
+
+   0x01, Redirection, [RFC3720]
+
+   0x02, Initiator Error, [RFC3720]
+
+   0x03, Target Error, [RFC3720]
+
+   0x0f, Vendor-Unique, this document
+
+   Initial sub-registry contents (Status-Detail for Status-Class=0x00):
+
+   0x00, 0x00, Success, [RFC3720]
+
+   1-255: range reserved by IANA for assignment in Status-Class=0 sub-
+   registry.
+
+   Initial sub-registry contents (Status-Detail for Status-Class=0x01):
+
+   0x01, 0x01, Temporary move, [RFC3720]
+
+   0x01, 0x02, Permanent move, [RFC3720]
+
+   3-255: range reserved by IANA for assignment in Status-Class=1 sub-
+   registry.
+
+   Initial sub-registry contents (Status-Detail for Status-Class=0x02):
+
+   0x02, 0x00, Miscellaneous, [RFC3720]
+
+   0x02, 0x01, Authentication failure, [RFC3720]
+
+   0x02, 0x02, Authorization failure, [RFC3720]
+
+   0x02, 0x03, Not found, [RFC3720]
+
+   0x02, 0x04, Target removed, [RFC3720]
+
+   0x02, 0x05, Unsupported version, [RFC3720]
+
+   0x02, 0x06, Too many connections, [RFC3720]
+
+   0x02, 0x07, Missing parameter, [RFC3720]
+
+
+
+Chadalapaka                 Standards Track                    [Page 33]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+   0x02, 0x08, Can't include in session, [RFC3720]
+
+   0x02, 0x09, Unsupported session type, [RFC3720]
+
+   0x02, 0x0a, Non-existent session, [RFC3720]
+
+   0x02, 0x0b, Invalid during login, [RFC3720]
+
+   12-255: range reserved by IANA for assignment in Status-Class=2 sub-
+   registry.
+
+   Initial sub-registry contents (Status-Detail for Status-Class=0x03):
+
+   0x03, 0x00, Target error, [RFC3720]
+
+   0x03, 0x01, Service unavailable, [RFC3720]
+
+   0x03, 0x02, Out of resources, [RFC3720]
+
+   3-255: range reserved by IANA for assignment in Status-Class=3 sub-
+   registry.
+
+   Allocation Policy:
+
+   Standards Action ([IANA])
+
+11.7.  iSCSI Reject Reason Codes
+
+   Name of the registry: "iSCSI Reject Reason Codes"
+
+   Namespace details: Numerical values that can fit in a single octet.
+
+   Information that must be provided to assign a new value: A published
+   specification defining the semantics and interoperability
+   requirements of the proposed new Code and the fields to be recorded
+   in the registry.
+
+   Assignment policy:
+
+   If the requested value is not already assigned, it may be assigned to
+   the requester.
+
+   13-255: range reserved by IANA for assignment in this registry.
+
+   Fields to record in the registry: Assigned Code, Description, and its
+   associated RFC reference.
+
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 34]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+   Initial registry contents:
+
+   0x01, Reserved, [RFC3720]
+
+   0x02, Data digest error, [RFC3720]
+
+   0x03, SNACK Reject, [RFC3720]
+
+   0x04, Protocol Error, [RFC3720]
+
+   0x05, Command not supported, [RFC3720]
+
+   0x06, Immediate command reject, [RFC3720]
+
+   0x07, Task in progress, [RFC3720]
+
+   0x08, Invalid data ack, [RFC3720]
+
+   0x09, Invalid PDU field, [RFC3720]
+
+   0x0a, Long op reject, [RFC3720]
+
+   0x0b, "Deprecated reason code", this document
+
+   0x0c, Waiting for Logout, [RFC3720]
+
+   Allocation Policy:
+
+   Standards Action ([IANA])
+
+11.8.  iSER Opcodes
+
+   Name of the registry: "iSER Opcodes"
+
+   Namespace details: Numerical values that can fit in 4 bits.
+
+   Information that must be provided to assign a new value: An IESG-
+   approved specification defining the semantics and interoperability
+   requirements of the proposed new value and the fields to be recorded
+   in the registry.
+
+   Assignment policy:
+
+   If the requested value is not already assigned, it may be assigned to
+   the requester.
+
+   4-15: range reserved by IANA for assignment in this registry.
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 35]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+   Fields to record in the registry: Assigned value, Operation Name, and
+   its associated RFC reference.
+
+   Initial registry contents:
+
+   0x1, iSCSI control-type, [iSER]
+
+   0x2, iSER Hello, [iSER]
+
+   0x3, iSER HelloReply, [iSER]
+
+   Allocation Policy:
+
+   Standards Action ([IANA])
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and
+             E. Zeidner, "Internet Small Computer Systems Interface
+             (iSCSI)", RFC 3720, April 2004.
+
+   [SPC3]    ANSI INCITS 408-2005, SCSI Primary Commands-3.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [IANA]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
+             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+             October 1998.
+
+   [iSER]    Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah, H.,
+             and P. Thaler, "Internet Small Computer System Interface
+             (iSCSI) Extensions for Remote Direct Memory Access (RDMA)",
+             RFC 5046, October 2007.
+
+12.2.  Informative References
+
+   [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M.
+             Krueger, "Internet Small Computer Systems Interface (iSCSI)
+             Naming and Discovery", RFC 3721, April 2004.
+
+   [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
+             Travostino, "Securing Block Storage Protocols over IP", RFC
+             3723, April 2004.
+
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 36]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+   [RFC3722] Bakke, M., "String Profile for Internet Small Computer
+             Systems Interface (iSCSI) Names", RFC 3722, April 2004.
+
+   [SAM2]    ANSI INCITS 366-2003, SCSI Architecture Model-2 (SAM-2).
+
+   [SAM3]    ANSI INCITS 402-2005, SCSI Architecture Model-3 (SAM-a3).
+
+   [SAM4]    T10 Project: 1683-D, SCSI Architecture Model-4 (SAM-4),
+             Work in Progress.
+
+Acknowledgements
+
+   The IP Storage (IPS) Working Group in the Transport Area of the IETF
+   has been responsible for defining the iSCSI protocol (apart from a
+   host of other relevant IP Storage protocols).  The editor
+   acknowledges the contributions of the entire working group.
+
+   The following individuals directly contributed to identifying
+   [RFC3720] issues and/or suggesting resolutions to the issues
+   clarified in this document: David Black, Gwendal Grignou, Mike Ko,
+   Dmitry Fomichev, Bill Studenmund, Ken Sandars, Bob Russell, Julian
+   Satran, Rob Elliott, Joseph Pittman, Somesh Gupta, Eddy Quicksall,
+   Paul Koning.  This document benefited from all of these
+   contributions.
+
+Editor's Address
+
+   Mallikarjun Chadalapaka
+   Hewlett-Packard Company
+   8000 Foothills Blvd.
+   Roseville, CA 95747-5668, USA
+   Phone: +1-916-785-5621
+   EMail: cbm@rose.hp.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 37]
+
+RFC 5048          iSCSI Corrections and Clarifications      October 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Chadalapaka                 Standards Track                    [Page 38]
+