idnits 2.17.1 draft-ietf-ips-iscsi-impl-guide-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1198. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1210. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1218. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1224. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document updates RFC3720, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2007) is 6070 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3720 (Obsoleted by RFC 7143) ** Downref: Normative reference to an Informational RFC: RFC 3721 -- Possible downref: Non-RFC (?) normative reference: ref. 'SPC3' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Mallikarjun Chadalapaka 3 draft-ietf-ips-iscsi-impl-guide-05.txt Hewlett-Packard Co. 4 Editor 6 Expires 7 August 2007 9 iSCSI Corrections and Clarifications 11 Status of this Memo 12 By submitting this Internet-Draft, each author represents 13 that any applicable patent or other IPR claims of which he or 14 she is aware have been or will be disclosed, and any of which 15 he or she becomes aware will be disclosed, in accordance with 16 Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet 19 Engineering Task Force (IETF), its areas, and its working 20 groups. Note that other groups may also distribute working 21 documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of 24 six months and may be updated, replaced, or obsoleted by 25 other documents at any time. It is inappropriate to use 26 Internet-Drafts as reference material or to cite them other 27 than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed 33 at http://www.ietf.org/shadow.html. 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 36 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 37 "OPTIONAL" in this document are to be interpreted as 38 described in [RFC2119]. 40 Abstract 41 iSCSI is a SCSI transport protocol and maps the SCSI family 42 of application protocols onto TCP/IP. RFC 3720 defines the 43 iSCSI protocol. This document compiles the clarifications to 44 the original protocol definition in RFC 3720 to serve as a 45 companion document for the iSCSI implementers. This document 46 updates RFC 3720 and the text in this document supersedes the 47 text in RFC 3720 when the two differ. 49 Table of Contents 51 1 Definitions and acronyms ...............................5 52 1.1 Definitions ............................................5 53 1.2 Acronyms ...............................................5 54 2 Introduction ...........................................7 55 3 iSCSI semantics for SCSI tasks .........................8 56 3.1 Residual handling ......................................8 57 3.1.1 Overview..............................................8 58 3.1.2 SCSI REPORT LUNS and Residual Overflow................9 59 3.2 R2T Ordering ..........................................10 60 3.3 Model Assumptions for Response Ordering ...............11 61 3.3.1 Model Description....................................11 62 3.3.2 iSCSI Semantics with the Interface Model.............12 63 3.3.3 Current List of Fenced Response Use Cases............12 64 4 Task Management .......................................14 65 4.1 Requests Affecting Multiple Tasks .....................14 66 4.1.1 Scope of affected tasks..............................14 67 4.1.2 Clarified multi-task abort semantics.................14 68 4.1.3 Updated multi-task abort semantics...................16 69 4.1.4 Affected tasks shared across RFC3720 & FastAbort 70 sessions....................................................18 71 4.1.5 Implementation considerations........................19 72 4.1.6 Rationale behind the new semantics...................20 73 5 Discovery semantics ...................................22 74 5.1 Error Recovery for Discovery Sessions .................22 75 5.2 Reinstatement Semantics of Discovery Sessions .........22 76 5.2.1 Unnamed Discovery Sessions...........................23 77 5.2.2 Named Discovery Sessions.............................23 78 5.3 Target PDUs during Discovery ..........................24 79 6 Negotiation and Others ................................25 80 6.1 TPGT Values ...........................................25 81 6.2 SessionType Negotiation ...............................25 82 6.3 Understanding NotUnderstood ...........................25 83 6.4 Outstanding Negotiation Exchanges .....................26 84 7 iSCSI Error Handling and Recovery .....................27 85 7.1 ITT ...................................................27 86 7.2 Format Errors .........................................27 87 7.3 Digest Errors .........................................27 88 7.4 Message Error Checking ................................28 89 8 iSCSI PDUs ............................................29 90 8.1 Asynchronous Message ..................................29 91 8.2 Reject ................................................29 92 9 Login/Text Operational Text Keys ......................30 93 9.1 TaskReporting .........................................30 94 10 Security Considerations ...............................32 95 11 IANA Considerations ...................................33 96 12 References and Bibliography ...........................34 97 12.1 Normative References.................................34 98 12.2 Informative References...............................34 99 13 Editor's Address ......................................35 100 14 Acknowledgements ......................................36 101 15 Full Copyright Statement ..............................37 102 16 Intellectual Property Statement .......................38 104 1 Definitions and acronyms 106 1.1 Definitions 108 I/O Buffer - A buffer that is used in a SCSI Read or Write 109 operation so SCSI data may be sent from or received into 110 that buffer. For a read or write data transfer to take 111 place for a task, an I/O Buffer is required on the 112 initiator and at least one required on the target. 114 SCSI-Presented Data Transfer Length (SPDTL): SPDTL is the 115 aggregate data length of the data that SCSI layer 116 logically "presents" to iSCSI layer for a Data-in or 117 Data-out transfer in the context of a SCSI task. For a 118 bidirectional task, there are two SPDTL values - one for 119 Data-in and one for Data-out. Note that the notion of 120 "presenting" includes immediate data per the data 121 transfer model in [SAM2], and excludes overlapping data 122 transfers, if any, requested by the SCSI layer. 124 Third-party: A term used in this document to denote nexus 125 objects (I_T or I_T_L) and iSCSI sessions which reap the 126 side-effects of actions that take place in the context of 127 a separate iSCSI session, while being third parties to 128 the action that caused the side-effects. One example of 129 a Third-party session is an iSCSI session hosting an 130 I_T_L nexus to an LU that is reset with an LU Reset TMF 131 via a separate I_T nexus. 133 1.2 Acronyms 135 Acronym Definition 137 ------------------------------------------------------------- 139 EDTL Expected Data Transfer Length 141 IANA Internet Assigned Numbers Authority 143 IETF Internet Engineering Task Force 145 I/O Input - Output 147 IP Internet Protocol 149 iSCSI Internet SCSI 151 iSER iSCSI Extensions for RDMA 153 ITT Initiator Task Tag 155 LO Leading Only 157 LU Logical Unit 159 LUN Logical Unit Number 161 PDU Protocol Data Unit 163 RDMA Remote Direct Memory Access 165 R2T Ready To Transfer 167 R2TSN Ready To Transfer Sequence Number 169 RFC Request For Comments 171 SAM SCSI Architecture Model 173 SCSI Small Computer Systems Interface 175 SN Sequence Number 177 SNACK Selective Negative Acknowledgment - also 179 Sequence Number Acknowledgement for data 181 TCP Transmission Control Protocol 183 TMF Task Management Function 185 TTT Target Transfer Tag 187 UA Unit Attention 189 2 Introduction 191 Several iSCSI implementations had been built after [RFC3720] was 192 published and the iSCSI community is now richer by the resulting 193 implementation expertise. The goal of this document is to 194 leverage this expertise both to offer clarifications to the 195 [RFC3720] semantics and to address defects in [RFC3720] as 196 appropriate. This document intends to offer critical guidance 197 to implementers with regard to non-obvious iSCSI implementation 198 aspects so as to improve interoperability and accelerate iSCSI 199 adoption. This document, however, does not purport to be an 200 all-encompassing iSCSI how-to guide for implementers, nor a 201 complete revision of [RFC3720]. This document instead is 202 intended as a companion document to [RFC3720] for the iSCSI 203 implementers. 205 iSCSI implementers are required to reference [RFC3722] and 206 [RFC3723] in addition to [RFC3720] for mandatory requirements. 207 In addition, [RFC3721] also contains useful information for 208 iSCSI implementers. The text in this document, however, updates 209 and supersedes the text in [RFC3720] and [RFC3721] whenever 210 there is such a question. 212 3 iSCSI semantics for SCSI tasks 214 3.1 Residual handling 216 Section 10.4.1 of [RFC3720] defines the notion of "residuals" 217 and specifies how the residual information should be encoded 218 into the SCSI Response PDU in Counts and Flags fields. Section 219 3.1.1 clarifies the intent of [RFC3720] and explains the general 220 principles. Section 3.1.2 describes the residual handling in 221 the REPORT LUNS scenario. 223 3.1.1 Overview 225 SCSI-Presented Data Transfer Length (SPDTL) is the term this 226 document uses (see section 1.1 for definition) to represent the 227 aggregate data length that the target SCSI layer attempts to 228 transfer using the local iSCSI layer for a task. Expected Data 229 Transfer Length (EDTL) is the iSCSI term that represents the 230 length of data that the iSCSI layer expects to transfer for a 231 task. EDTL is specified in the SCSI Command PDU. 233 When SPDTL = EDTL for a task, the target iSCSI layer completes 234 the task with no residuals. Whenever SPDTL differs from EDTL 235 for a task, that task is said to have a residual. 237 If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in 238 the SCSI Response PDU as specified in [RFC3720]. Residual Count 239 MUST be set to the numerical value of (SPDTL - EDTL). 241 If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in 242 the SCSI Response PDU as specified in [RFC3720]. Residual Count 243 MUST be set to the numerical value of (EDTL - SPDTL). 245 Note that the Overflow and Underflow scenarios are independent 246 of Data-in and Data-out. Either scenario is logically possible 247 in either direction of data transfer. 249 3.1.2 SCSI REPORT LUNS and Residual Overflow 251 This section discusses the residual overflow issues citing the 252 example of SCSI REPORT LUNS command. Note however that there 253 are several SCSI commands (e.g. INQUIRY) with ALLOCATION LENGTH 254 fields following the same underlying rules. The semantics in 255 the rest of the section apply to all such SCSI commands. 257 The specification of the SCSI REPORT LUNS command requires that 258 the SCSI target limit the amount of data transferred to a 259 maximum size (ALLOCATION LENGTH) provided by the initiator in 260 the REPORT LUNS CDB. If the Expected Data Transfer Length 261 (EDTL) in the iSCSI header of the SCSI Command PDU for a REPORT 262 LUNS command is set to at least as large as that ALLOCATION 263 LENGTH, the SCSI layer truncation prevents an iSCSI Residual 264 Overflow from occurring. A SCSI initiator can detect that such 265 truncation has occurred via other information at the SCSI layer. 266 The rest of the section elaborates this required behavior. 268 iSCSI uses the (O) bit (bit 5) in the Flags field of the SCSI 269 Response and the last SCSI Data-In PDUs to indicate that that an 270 iSCSI target was unable to transfer all of the SCSI data for a 271 command to the initiator because the amount of data to be 272 transferred exceeded the EDTL in the corresponding SCSI Command 273 PDU (see Section 10.4.1 of [RFC3720]). 275 The SCSI REPORT LUNS command requests a target SCSI layer to 276 return a logical unit inventory (LUN list) to the initiator SCSI 277 layer (see section 6.21 of SPC-3 [SPC3]). The size of this LUN 278 list may not be known to the initiator SCSI layer when it issues 279 the REPORT LUNS command; to avoid transfer of more LUN list data 280 than the initiator is prepared for, the REPORT LUNS CDB contains 281 an ALLOCATION LENGTH field to specify the maximum amount of data 282 to be transferred to the initiator for this command. If the 283 initiator SCSI layer has under-estimated the number of logical 284 units at the target, it is possible that the complete logical 285 unit inventory does not fit in the specified ALLOCATION LENGTH. 286 In this situation, section 4.3.3.6 in [SPC3] requires that the 287 target SCSI layer "shall terminate transfers to the Data-In 288 Buffer" when the number of bytes specified by the ALLOCATION 289 LENGTH field have been transferred. 291 Therefore, in response to a REPORT LUNS command, the SCSI layer 292 at the target presents at most ALLOCATION LENGTH bytes of data 293 (logical unit inventory) to iSCSI for transfer to the initiator. 294 For a REPORT LUNS command, if the iSCSI EDTL is at least as 295 large as the ALLOCATION LENGTH, the SCSI truncation ensures that 296 the EDTL will accommodate all of the data to be transferred. If 297 all of the logical unit inventory data presented to the iSCSI 298 layer - i.e. the data remaining after any SCSI truncation - is 299 transferred to the initiator by the iSCSI layer, an iSCSI 300 Residual Overflow has not occurred and the iSCSI (O) bit MUST 301 NOT be set in the SCSI Response or final SCSI Data-Out PDU. 302 This is not a new requirement but is already required by the 303 combination of [RFC3720] with the specification of the REPORT 304 LUNS command in [SPC3]. If the iSCSI EDTL is larger than the 305 ALLOCATION LENGTH however in this scenario, note that the iSCSI 306 Underflow MUST be signaled in the SCSI Response PDU. An iSCSI 307 Underflow MUST also be signaled when the iSCSI EDTL is equal to 308 ALLOCATION LENGTH but the logical unit inventory data presented 309 to the iSCSI layer is smaller than ALLOCATION LENGTH. 311 The LUN LIST LENGTH field in the logical unit inventory (first 312 field in the inventory) is not affected by truncation of the 313 inventory to fit in ALLOCATION LENGTH; this enables a SCSI 314 initiator to determine that the received inventory is incomplete 315 by noticing that the LUN LIST LENGTH in the inventory is larger 316 than the ALLOCATION LENGTH that was sent in the REPORT LUNS CDB. 317 A common initiator behavior in this situation is to re-issue the 318 REPORT LUNS command with a larger ALLOCATION LENGTH. 320 3.2 R2T Ordering 322 Section 10.8 in [RFC3720] says the following: 324 The target may send several R2T PDUs. It, therefore, can have 325 a number of pending data transfers. The number of outstanding 326 R2T PDUs are limited by the value of the negotiated key 327 MaxOutstandingR2T. Within a connection, outstanding R2Ts MUST 328 be fulfilled by the initiator in the order in which they were 329 received. 331 The quoted [RFC3720] text was unclear on the scope of 332 applicability - either per task, or across all tasks on a 333 connection - and may be interpreted as either. This section is 334 intended to clarify that the scope of applicability of the 335 quoted text is a task. No R2T ordering relationship - either in 336 generation at the target or in fulfilling at the initiator - 337 across tasks is implied. I.e., outstanding R2Ts within a task 338 MUST be fulfilled by the initiator in the order in which they 339 were received on a connection. 341 3.3 Model Assumptions for Response Ordering 343 Whenever an iSCSI session is composed of multiple connections, 344 the Response PDUs (task responses or TMF responses) originating 345 in the target SCSI layer are distributed onto the multiple 346 connections by the target iSCSI layer according to iSCSI 347 connection allegiance rules. This process generally may not 348 preserve the ordering of the responses by the time they are 349 delivered to the initiator SCSI layer. Since ordering is not 350 expected across SCSI responses anyway, this approach works fine 351 in the general case. However to address the special cases where 352 some ordering is desired by the SCSI layer, the following 353 "Response Fence" semantics are defined with respect to handling 354 SCSI response messages as they are handed off from the SCSI 355 protocol layer to the iSCSI layer. 357 3.3.1 Model Description 359 Target SCSI protocol layer hands off the SCSI response messages 360 to the target iSCSI layer by invoking the "Send Command 361 Complete" protocol data service ([SAM2], clause 5.4.2) and "Task 362 Management Function Executed" ([SAM2], clause 6.9) service. On 363 receiving the SCSI response message, iSCSI layer exhibits the 364 Response Fence behavior for certain SCSI response messages 365 (section 3.3.3 describes the specific instances where the 366 semantics must be realized). Whenever the Response Fence 367 behavior is required for a SCSI response message, the target 368 iSCSI layer MUST ensure that the following conditions are met in 369 delivering the response message to the initiator iSCSI layer: 371 (1) Response with Response Fence MUST chronologically be 372 delivered after all the "preceding" responses on the 373 I_T_L nexus, if the preceding responses are delivered at 374 all, to the initiator iSCSI layer. 376 (2) Response with Response Fence MUST chronologically be 377 delivered prior to all the "following" responses on the 378 I_T_L nexus. 380 The "preceding" and "following" notions refer to the order of 381 hand-off of a response message from the target SCSI protocol 382 layer to the target iSCSI layer. 384 3.3.2 iSCSI Semantics with the Interface Model 386 Whenever the TaskReporting key (section 9.1) is negotiated to 387 ResponseFence or FastAbort for an iSCSI session and the Response 388 Fence behavior is required for a SCSI response message, the 389 target iSCSI layer MUST perform the actions described in this 390 section for that session.: 392 a) If it is a single-connection session, no special processing 393 is required. Standard SCSI Response PDU build and dispatch 394 process happens. 396 b) If it is a multi-connection session, target iSCSI layer 397 takes note of last-sent and unacknowledged StatSN on each 398 of the connections in the iSCSI session, and waits for 399 acknowledgement (SHOULD solicit for acknowledgement by way 400 of a Nop-In) of each such StatSN to clear the fence. SCSI 401 response with the Response Fence flag must be sent to the 402 initiator only after receiving acknowledgements for each of 403 the unacknowledged StatSNs. 405 c) Target iSCSI layer must wait for an acknowledgement of the 406 SCSI Response PDU that carried the response which the 407 target SCSI layer marked with the Response Fence flag. The 408 fence must be considered cleared after receiving the 409 acknowledgement. 411 d) All further status processing for the LU is resumed only 412 after clearing the fence. If any new responses for the 413 I_T_L nexus are received from the SCSI layer before the 414 fence is cleared, those Response PDUs must be held and 415 queued at the iSCSI layer until the fence is cleared. 417 3.3.3 Current List of Fenced Response Use Cases 419 This section lists the fenced response use cases that iSCSI 420 implementations must comply with. However, this is not an 421 exhaustive enumeration. It is expected that as SCSI protocol 422 specifications evolve, the specifications will specify when 423 response fencing is required on a case-by-case basis. 425 Whenever the TaskReporting key (section 9.1) is negotiated to 426 ResponseFence or FastAbort for an iSCSI session, target iSCSI 427 layer MUST assume that Response Fence flag is set by the target 428 SCSI layer on the following SCSI completion messages handed down 429 to it: 431 1. The first completion message carrying the UA after the 432 multi-task abort on issuing and third-party sessions. 434 2. The TMF Response carrying the multi-task TMF Response on 435 the issuing session. 437 3. The completion message indicating ACA establishment on the 438 issuing session. 440 4. The first completion message carrying the ACA ACTIVE status 441 after ACA establishment on issuing and third-party 442 sessions. 444 5. The TMF Response carrying the Clear ACA response on the 445 issuing session. 447 6. The response to a PERSISTENT RESERVE OUT/PREEMPT AND ABORT 448 command 450 Note: Due to the absence of ACA-related fencing requirements in 451 [RFC3720], initiator implementations SHOULD NOT use ACA on 452 multi-connection iSCSI sessions to targets complying only with 453 [RFC3720]. Initiators which want to employ ACA on multi- 454 connection iSCSI sessions SHOULD first assess response fencing 455 behavior via negotiating for ResponseFence or FastAbort values 456 for the TaskReporting (section 9.1) key. 458 4 Task Management 460 4.1 Requests Affecting Multiple Tasks 462 This section clarifies and updates the original text in section 463 10.6.2 of [RFC3720]. The clarified semantics (section 4.1.2) 464 are a superset of the protocol behavior required in the original 465 text and all iSCSI implementations MUST support the new 466 behavior. The updated semantics (section 4.1.3) on the other 467 hand are mandatory only when the new key TaskReporting (section 468 9.1) is negotiated to "FastAbort". 470 4.1.1 Scope of affected tasks 472 This section defines the notion of "affected tasks" in multi- 473 task abort scenarios. Scope definitions in this section apply 474 to both the clarified protocol behavior (section 4.1.2) and the 475 updated protocol behavior (section 4.1.3). 477 ABORT TASK SET: All outstanding tasks for the I_T_L nexus 478 identified by the LUN field in the ABORT TASK SET TMF 479 Request PDU. 481 CLEAR TASK SET: All outstanding tasks in the task set for 482 the LU identified by the LUN field in the CLEAR TASK SET 483 TMF Request PDU. See [SPC3] for the definition of a "task 484 set". 486 LOGICAL UNIT RESET: All outstanding tasks from all 487 initiators for the LU identified by the LUN field in the 488 LOGICAL UNIT RESET Request PDU. 490 TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks 491 from all initiators across all LUs to which the TMF-issuing 492 session has access to on the SCSI target device hosting the 493 iSCSI session. 495 Usage: an "ABORT TASK SET TMF Request PDU" in the preceding text 496 is an iSCSI TMF Request PDU with the "Function" field set to 497 "ABORT TASK SET" as defined in [RFC3720]. Similar usage is 498 employed for other scope descriptions. 500 4.1.2 Clarified multi-task abort semantics 502 All iSCSI implementations MUST support the protocol behavior 503 defined in this section as the default behavior. The execution 504 of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET 505 WARM RESET, and TARGET COLD RESET TMF Requests consists of the 506 following sequence of actions in the specified order on the 507 specified party. 509 The initiator iSCSI layer: 511 a. MUST continue to respond to each TTT received for the 512 affected tasks. 514 b. Should receive any responses that the target may provide 515 for some tasks among the affected tasks (may process them 516 as usual because they are guaranteed to have 517 chronologically originated prior to the TMF response). 519 c. Should receive the TMF Response concluding all the tasks in 520 the set of affected tasks. 522 The target iSCSI layer: 524 a. MUST wait for responses on currently valid target transfer 525 tags of the affected tasks from the issuing initiator. MAY 526 wait for responses on currently valid target transfer tags 527 of the affected tasks from third-party initiators. 529 b. MUST wait (concurrent with the wait in Step.a) for all 530 commands of the affected tasks to be received based on the 531 CmdSN ordering. SHOULD NOT wait for new commands on 532 third-party affected sessions - only the instantiated tasks 533 have to be considered for the purpose of determining the 534 affected tasks. In the case of target-scoped requests 535 (i.e. TARGET WARM RESET and TARGET COLD RESET), all the 536 commands that are not yet received on the issuing session 537 in the command stream however can be considered to have 538 been received with no command waiting period - i.e. the 539 entire CmdSN space up to the CmdSN of the task management 540 function can be "plugged". 542 c. MUST propagate the TMF request to and receive the response 543 from the target SCSI layer. 545 d. MUST address the Response Fence flag on the TMF Response on 546 issuing session as defined in 3.3.2. 548 e. MUST address the Response Fence flag on the first post-TMF 549 Response on third-party sessions as defined in 3.3.2. If 550 some tasks originate from non-iSCSI I_T_L nexuses then the 551 means by which the target ensures that all affected tasks 552 have returned their status to the initiator are defined by 553 the specific non-iSCSI transport protocol(s). 555 Implementation note: Technically, the TMF servicing is complete 556 in Step.d. Data transfers corresponding to terminated tasks may 557 however still be in progress on third-party iSCSI sessions even 558 at the end of Step.e. TMF Response MUST NOT be sent by the 559 target iSCSI layer before the end of Step.d, and MAY be sent at 560 the end of Step.d despite these outstanding data transfers until 561 after Step.e. 563 4.1.3 Updated multi-task abort semantics 565 Protocol behavior defined in this section MUST be implemented by 566 all iSCSI implementations complying with this document. 567 Protocol behavior defined in this section MUST be exhibited by 568 iSCSI implementations on an iSCSI session when they negotiate 569 the TaskReporting (section 9.1) key to "FastAbort" on that 570 session. The execution of ABORT TASK SET, CLEAR TASK SET, 571 LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF 572 Requests consists of the following sequence of actions in the 573 specified order on the specified party. 575 The initiator iSCSI layer: 577 a. MUST NOT send any more Data-Out PDUs for affected tasks on 578 the issuing connection of the issuing iSCSI session once 579 the TMF is sent to the target. 581 b. Should receive any responses that the target may provide 582 for some tasks among the affected tasks (may process them 583 as usual because they are guaranteed to have 584 chronologically originated prior to the TMF response). 586 c. MUST respond to each Async Message PDU with AsyncEvent=5 as 587 defined in section 8.1. 589 d. Should receive the TMF Response concluding all the tasks in 590 the set of affected tasks. 592 The target iSCSI layer: 594 a. MUST wait for all commands of the affected tasks to be 595 received based on the CmdSN ordering on the issuing 596 session. SHOULD NOT wait for new commands on third-party 597 affected sessions - only the instantiated tasks have to be 598 considered for the purpose of determining the affected 599 tasks. In the case of target-scoped requests (i.e. TARGET 600 WARM RESET and TARGET COLD RESET), all the commands that 601 are not yet received on the issuing session in the command 602 stream can be considered to have been received with no 603 command waiting period - i.e. the entire CmdSN space up to 604 the CmdSN of the task management function can be "plugged". 605 b. MUST propagate the TMF request to and receive the response 606 from the target SCSI layer. 608 c. MUST leave all active "affected TTTs" (i.e. active TTTs 609 associated with affected tasks) valid. 611 d. MUST send an Asynchronous Message PDU with AsyncEvent=5 612 (section 8.1) on: 613 i) each connection of each third-party session to which at 614 least one affected task is allegiant if 615 TaskReporting=FastAbort is operational on that third- 616 party session, and 617 ii) each connection except the issuing connection of the 618 issuing session that has at least one allegiant affected 619 task. 621 If there are multiple affected LUs (say due to a target 622 reset), then one Async Message PDU MUST be sent for each 623 such LU on each connection that has at least one allegiant 624 affected task. The LUN field in the Asynchronous Message 625 PDU MUST be set to match the LUN for each such LU. 627 e. MUST address the Response Fence flag on the TMF Response on 628 issuing session as defined in 3.3.2. 630 f. MUST address the Response Fence flag on the first post-TMF 631 Response on third-party sessions as defined in 3.3.2. If 632 some tasks originate from non-iSCSI I_T_L nexuses then the 633 means by which the target ensures that all affected tasks 634 have returned their status to the initiator are defined by 635 the specific non-iSCSI transport protocol(s). 637 g. MUST free up the affected TTTs (and STags, if applicable) 638 and the corresponding buffers, if any, once it receives 639 each associated Nop-Out acknowledgement that the initiator 640 generated in response to each Async Message. 642 Implementation note: Technically, the TMF servicing is complete 643 in Step.e. Data transfers corresponding to terminated tasks may 644 however still be in progress even at the end of Step.f. TMF 645 Response MUST NOT be sent by the target iSCSI layer before the 646 end of Step.e, and MAY be sent at the end of Step.e despite 647 these outstanding Data transfers until Step.g. Step.g specifies 648 an event to free up any such resources that may have been 649 reserved to support outstanding data transfers. 651 4.1.3.1 Clearing effects update 653 Appendix F.1 of [RFC3720] specifies the clearing effects of 654 target and LU resets on "Incomplete TTTs" as "Y". This meant 655 that a target warm reset or a target cold reset or an LU reset 656 would clear the active TTTs upon completion. The 657 TaskReporting=FastAbort (section 9.1) semantics defined by this 658 section however do not guarantee that the active TTTs are 659 cleared by the end of the reset operations. In fact, the new 660 semantics are designed to allow clearing the TTTs in a "lazy" 661 fashion after the TMF Response is delivered. Thus, when 662 TaskReporting=FastAbort is operational on a session, the 663 clearing effects of reset operations on "Incomplete TTTs" is 664 "N". 666 4.1.4 Affected tasks shared across RFC3720 & FastAbort sessions 668 If an iSCSI target implementation is capable of supporting 669 TaskReporting=FastAbort functionality (section 9.1), it may end 670 up in a situation where some sessions have TaskReporting=RFC3720 671 operational (RFC3720 sessions) while some other sessions have 672 TaskReporting=FastAbort operational (FastAbort sessions) even 673 while accessing a shared set of affected tasks (section 4.1.1). 675 If the issuing session is a RFC3720 session, iSCSI target 676 implementation is FastAbort-capable and third-party affected 677 session is a FastAbort session, the following behavior SHOULD be 678 exhibited by the iSCSI target layer: 680 a. Between steps c and d of target behavior in section 4.1.2, 681 send an Asynchronous Message PDU with AsyncEvent=5 (section 682 8.1) on each connection of each third-party session to 683 which at least one affected task is allegiant. If there 684 are multiple affected LUs, then send one Async Message PDU 685 for each such LU on each connection that has at least one 686 allegiant affected task. When sent, the LUN field in the 687 Asynchronous Message PDU MUST be set to match the LUN for 688 each such LU. 689 b. After step e of target behavior in section 4.1.2, free up 690 the affected TTTs (and STags, if applicable) and the 691 corresponding buffers, if any, once each associated Nop-Out 692 acknowledgement is received that the third-party initiator 693 generated in response to each Async Message sent in step a. 695 If the issuing session is a FastAbort session, iSCSI target 696 implementation is FastAbort-capable and third-party affected 697 session is a RFC3720 session, the following behavior MUST be 698 exhibited by the iSCSI target layer: Asynchronous Message PDUs 699 MUST NOT be sent on the third-party session to prompt the 700 FastAbort behavior. 702 If the third-party affected session is a FastAbort session and 703 issuing session is a FastAbort session, initiator in the third- 704 party role MUST respond to each Async Message PDU with 705 AsyncEvent=5 as defined in section 8.1. Note that an initiator 706 MAY thus receive these Async Messages on a third-party affected 707 session even if the session is a single-connection session. 709 4.1.5 Implementation considerations 711 Both in clarified semantics (section 4.1.2) and updated 712 semantics (section 4.1.3), there may be outstanding data 713 transfers even after the TMF completion is reported on the 714 issuing session. In the case of iSCSI/iSER [iSER], these would 715 be tagged data transfers for STags not owned by any active 716 tasks. Whether or not real buffers support these data transfers 717 is implementation-dependent. However, the data transfers 718 logically MUST be silently discarded by the target iSCSI layer 719 in all cases. A target MAY, on an implementation-defined 720 internal timeout, also choose to drop the connections on which 721 it did not receive the expected Data-out sequences (section 722 4.1.2) or Nop-Out acknowledgements (section 4.1.3) so as to 723 reclaim the associated buffer, STag and TTT resources as 724 appropriate. 726 4.1.6 Rationale behind the new semantics 728 There are fundamentally three basic objectives behind the 729 semantics specified in section 4.1.2 and section 4.1.3. 731 1. Maintaining an ordered command flow I_T nexus abstraction 732 to the target SCSI layer even with multi-connection 733 sessions. 735 o Target iSCSI processing of a TMF request must maintain 736 the single flow illusion. Target behavior in Step.b 737 of section 4.1.2 and Step.a of section 4.1.3 738 correspond to this objective. 740 2. Maintaining a single ordered response flow I_T nexus 741 abstraction to the initiator SCSI layer even with multi- 742 connection sessions when one response (i.e. TMF response) 743 could imply the status of other unfinished tasks from the 744 initiator's perspective. 746 o Target must ensure that the initiator does not see 747 "old" task responses (that were placed on the wire 748 chronologically earlier than the TMF Response) after 749 seeing the TMF response. Target behavior in Step.d of 750 section 4.1.2 and Step.e of section 4.1.3 correspond 751 to this objective. 753 o Whenever the result of a TMF action is visible across 754 multiple I_T_L nexuses, [SAM2] requires the SCSI 755 device server to trigger a UA on each of the other 756 I_T_L nexuses. Once an initiator is notified of such 757 an UA, the application client on the receiving 758 initiator is required to clear its task state (clause 759 5.5 in [SAM2]) for the affected tasks. It would thus 760 be inappropriate to deliver a SCSI Response for a task 761 after the task state is cleared on the initiator, i.e. 762 after the UA is notified. The UA notification 763 contained in the first SCSI Response PDU on each 764 affected Third-party I_T_L nexus after the TMF action 765 thus MUST NOT pass the affected task responses on any 766 of the iSCSI sessions accessing the LU. Target 767 behavior in Step.e of section 4.1.2 and Step.f of 768 section 4.1.3 correspond to this objective. 770 3. Draining all active TTTs corresponding to affected tasks 771 in a deterministic fashion. 773 o Data-out PDUs with stale TTTs arriving after the tasks 774 are terminated can create a buffer management problem 776 even for traditional iSCSI implementations, and is 777 fatal for the connection for iSCSI/iSER 778 implementations. Either the termination of affected 779 tasks should be postponed until the TTTs are retired 780 (as in Step.a of section 4.1.2), or the TTTs and the 781 buffers should stay allocated beyond task termination 782 to be deterministically freed up later (as in Step.c 783 and Step.g of section 4.1.3). 785 The only other notable optimization is the plugging. If all 786 tasks on an I_T nexus will be aborted anyway (as with a target 787 reset), there is no need to wait to receive all commands to plug 788 the CmdSN holes. Target iSCSI layer can simply plug all missing 789 CmdSN slots and move on with TMF processing. The first 790 objective (maintaining a single ordered command flow) is still 791 met with this optimization because target SCSI layer only sees 792 ordered commands. 794 5 Discovery semantics 796 5.1 Error Recovery for Discovery Sessions 798 The negotiation of the key ErrorRecoveryLevel is not required 799 for Discovery sessions - i.e. for sessions that negotiated 800 "SessionType=Discovery" - because the default value of 0 is 801 necessary and sufficient for Discovery sessions. It is however 802 possible that some legacy iSCSI implementations might attempt to 803 negotiate the ErrorRecoveryLevel key on Discovery sessions. 804 When such a negotiation attempt is made by the remote side, a 805 compliant iSCSI implementation MUST propose a value of 0 (zero) 806 in response. The operational ErrorRecoveryLevel for Discovery 807 sessions thus MUST be 0. This naturally follows from the 808 functionality constraints [RFC3720] imposes on Discovery 809 sessions. 811 5.2 Reinstatement Semantics of Discovery Sessions 813 Discovery sessions are intended to be relatively short-lived. 814 Initiators are not expected to establish multiple Discovery 815 sessions to the same iSCSI Network Portal (see [RFC3720]). An 816 initiator may use the same iSCSI Initiator Name and ISID when 817 establishing different unique sessions with different targets 818 and/or different portal groups. This behavior is discussed in 819 Section 9.1.1 of [RFC3720] and is, in fact, encouraged as 820 conservative reuse of ISIDs. ISID RULE in [RFC3720] states that 821 there must not be more than one session with a matching 4-tuple: 822 . While 823 the spirit of the ISID RULE applies to Discovery sessions the 824 same as it does for Normal sessions, note that some Discovery 825 sessions differ from the Normal sessions in two important 826 aspects: 828 Because [RFC3720] allows a Discovery session to be 829 established without specifying a TargetName key in the 830 Login Request PDU (let us call such a session an "Unnamed" 831 Discovery session), there is no Target Node context to 832 enforce the ISID RULE. 834 Portal Groups are defined only in the context of a Target 835 Node. When the TargetName key is NULL-valued (i.e. not 836 specified), the TargetPortalGroupTag thus cannot be 837 ascertained to enforce the ISID RULE. 839 The following sections describe the two scenarios - Named 840 Discovery sessions and Unnamed Discovery sessions - separately. 842 5.2.1 Unnamed Discovery Sessions 844 For Unnamed Discovery sessions, neither the TargetName nor the 845 TargetPortalGroupTag is available to the targets in order to 846 enforce the ISID RULE. So the following rule applies. 848 UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the 849 following 4-tuple for Unnamed Discovery sessions: 850 . The following 851 semantics are implied by this uniqueness requirement. 853 Targets SHOULD allow concurrent establishment of one Discovery 854 session with each of its Network Portals by the same initiator 855 port with a given iSCSI Node Name and an ISID. Each of the 856 concurrent Discovery sessions, if established by the same 857 initiator port to other Network Portals, MUST be treated as 858 independent sessions - i.e. one session MUST NOT reinstate the 859 other. 861 A new Unnamed Discovery session that has a matching 862 to an existing 863 discovery session MUST reinstate the existing Unnamed Discovery 864 session. Note thus that only an Unnamed Discovery session may 865 reinstate an Unnamed Discovery session. 867 5.2.2 Named Discovery Sessions 869 For a Named Discovery session, the TargetName key is specified 870 by the initiator and thus the target can unambiguously ascertain 871 the TargetPortalGroupTag as well. Since all the four elements 872 of the 4-tuple are known, the ISID RULE MUST be enforced by 873 targets with no changes from [RFC3720] semantics. A new session 874 with a matching thus will reinstate an existing session. 876 Note in this case that any new iSCSI session (Discovery or 877 Normal) with the matching 4-tuple may reinstate an existing 878 Named Discovery iSCSI session. 880 5.3 Target PDUs during Discovery 882 Targets SHOULD NOT send any responses other than a Text Response 883 and Logout Response on a Discovery session, once in full feature 884 phase. 886 Implementation Note: A target may simply drop the connection in 887 a Discovery session when it would have requested a Logout via an 888 Async Message on Normal sessions. 890 6 Negotiation and Others 892 6.1 TPGT Values 894 [SAM2] and [SAM3] specifications incorrectly note in their 895 informative text that TPGT value should be non-zero, although 896 [RFC3720] allows the value of zero for TPGT. This section is to 897 clarify that zero value is expressly allowed as a legal value 898 for TPGT. This discrepancy currently stands corrected in 899 [SAM4]. 901 6.2 SessionType Negotiation 903 During the Login phase, the SessionType key is offered by the 904 initiator to choose the type of session it wants to create with 905 the target. The target may accept or reject the offer. 906 Depending on the type of the session, a target may decide on 907 resources to allocate and the security to enforce etc. for the 908 session. If the SessionType key is thus going to be offered as 909 "Discovery", it SHOULD be offered in the initial Login request 910 by the initiator. 912 6.3 Understanding NotUnderstood 914 [RFC3720] defines NotUnderstood as a valid answer during a 915 negotiation text key exchange between two iSCSI nodes. 916 NotUnderstood has the reserved meaning that the sending side did 917 not understand the key semantics. This section seeks to clarify 918 that NotUnderstood is a valid answer for both declarative and 919 negotiated keys. The general iSCSI philosophy is that 920 comprehension precedes processing for any iSCSI key. A proposer 921 of an iSCSI key, negotiated or declarative, in a text key 922 exchange MUST thus be able to properly handle a NotUnderstood 923 response. 925 The proper way to handle a NotUnderstood response varies 926 depending on the lineage and type of the key. All keys defined 927 in [RFC3720] MUST be supported by all compliant implementations; 928 a NotUnderstood answer on any of the [RFC3720] keys therefore 929 MUST be considered a protocol error and handled accordingly. 930 For all other later keys, a NotUnderstood answer concludes the 931 negotiation for a negotiated key whereas for a declarative key, 932 a NotUnderstood answer simply informs the declarer of lack of 933 comprehension by the receiver. In either case, a NotUnderstood 934 answer always requires that the protocol behavior associated 935 with that key be not used within the scope of the key 936 (connection/session) by either side. 938 6.4 Outstanding Negotiation Exchanges 940 There was some uncertainty around the number of outstanding 941 Login Response PDUs on a connection. [RFC3720] offers the 942 analogy of SCSI linked commands to Login and Text negotiations 943 in sections 5.3 and 10.10.3 respectively, but does not make it 944 fully explicit. This section is to offer a clarification in 945 this regard. 947 There MUST NOT be more than one outstanding Login Request or 948 Login Response or Text Request or Text Response PDU on an iSCSI 949 connection. An outstanding PDU in this context is one that has 950 not been acknowledged by the remote iSCSI side. 952 7 iSCSI Error Handling and Recovery 954 7.1 ITT 956 Section 10.19 in [RFC3720] mentions this in passing but noted 957 here again for making it obvious since the semantics apply to 958 the initiators in general. An ITT value of 0xffffffff is 959 reserved and MUST NOT be assigned for a task by the initiator. 960 The only instance it may be seen on the wire is in a target- 961 initiated NOP-In PDU (and in the initiator response to that PDU 962 if necessary). 964 7.2 Format Errors 966 Section 6.6 of [RFC3720] discusses format error handling. This 967 section elaborates on the "inconsistent" PDU field contents 968 noted in [RFC3720]. 970 All initiator-detected PDU construction errors MUST be 971 considered as format errors. Some examples of such errors are: 973 - NOP-In with a valid TTT but an invalid LUN 975 - NOP-In with a valid ITT (i.e. a NOP-In response) and also a 976 valid TTT 978 - SCSI Response PDU with Status=CHECK CONDITION, but 979 DataSegmentLength = 0 981 7.3 Digest Errors 983 Section 6.7 of [RFC3720] discusses digest error handling. It 984 states that "No further action is necessary for initiators if 985 the discarded PDU is an unsolicited PDU (e.g., Async, Reject)" 986 on detecting a payload digest error. This is incorrect. 988 An Asynchronous Message PDU or a Reject PDU carries the next 989 StatSN value on an iSCSI connection, advancing the StatSN. When 990 an initiator discards one of these PDUs due to a payload digest 991 error, the entire PDU including the header MUST be discarded. 992 Consequently, the initiator MUST treat the exception like a loss 993 of any other solicited response PDU - i.e. it MUST use one of 994 the following options noted in [RFC3720]: 996 a) Request PDU retransmission with a status SNACK. 998 b) Logout the connection for recovery and continue the 999 tasks on a different connection instance. 1001 c) Logout to close the connection (abort all the commands 1002 associated with the connection). 1004 7.4 Message Error Checking 1006 There has been some uncertainty on the extent to which incoming 1007 messages have to be checked for protocol errors, beyond what is 1008 strictly required for processing the inbound message. This 1009 section addresses that question. 1011 Unless [RFC3720] or this draft requires it, an iSCSI 1012 implementation is not required to do an exhaustive protocol 1013 conformance checking on an incoming iSCSI PDU. The iSCSI 1014 implementation especially is not required to double-check the 1015 remote iSCSI implementation's conformance to protocol 1016 requirements. 1018 8 iSCSI PDUs 1020 8.1 Asynchronous Message 1022 This section defines additional semantics for the Asynchronous 1023 Message PDU defined in section 10.9 of [RFC3720] using the same 1024 conventions. 1026 The following new legal value for AsyncEvent is defined: 1028 5: all active tasks for LU with matching LUN field in the Async 1029 Message PDU are being terminated. 1031 The receiving initiator iSCSI layer MUST respond to this Message 1032 by taking the following steps in order. 1034 i) Stop Data-Out transfers on that connection for all active 1035 TTTs for the affected LUN quoted in the Async Message 1036 PDU. 1037 ii) Acknowledge the StatSN of the Async Message PDU via a 1038 Nop-Out PDU with ITT=0xffffffff (i.e. non-ping flavor), 1039 while copying the LUN field from Async Message to Nop- 1040 Out. 1042 8.2 Reject 1044 Section 10.17.1 of [RFC3720] specifies the Reject reason code of 1045 0x0b with an explanation of "Negotiation Reset". At this point, 1046 we do not see any legitimate iSCSI protocol use case for using 1047 this reason code. Thus reason code 0x0b MUST be considered as 1048 deprecated and MUST NOT be used by any new implementations. 1050 9 Login/Text Operational Text Keys 1052 This section follows the same conventions as section 12 of 1053 [RFC3720]. 1055 9.1 TaskReporting 1057 Use: LO 1058 Senders: Initiator and Target 1059 Scope: SW 1061 Irrelevant when: SessionType=Discovery 1062 TaskReporting= 1064 Default is RFC3720. 1065 Result function is AND. 1067 This key is used to negotiate the task completion reporting 1068 semantics from the SCSI target. Following table describes the 1069 semantics an iSCSI target MUST support for respective negotiated 1070 key values. Whenever this key is negotiated, at least the 1071 RFC3720 and ResponseFence values MUST be offered as options by 1072 the negotiation originator. 1074 +--------------+------------------------------------------+ 1075 | Name | Description | 1076 +--------------+------------------------------------------+ 1077 | RFC3720 | RFC 3720-compliant semantics. Response | 1078 | | fencing is not guaranteed and fast | 1079 | | completion of multi-task aborting is not | 1080 | | supported | 1081 +--------------+------------------------------------------+ 1082 | ResponseFence| Response Fence (section 3.3.1) semantics | 1083 | | MUST be supported in reporting task | 1084 | | completions | 1085 +--------------+------------------------------------------+ 1086 | FastAbort | Updated fast multi-task abort semantics | 1087 | | defined in section 4.1.3 MUST be | 1088 | | supported. Support for Response Fence is| 1089 | | implied - i.e. section 3.3.1 semantics | 1090 | | MUST be supported as well | 1091 +--------------+------------------------------------------+ 1092 When TaskReporting is not negotiated to FastAbort, the default 1093 behavior is to use the [RFC3720] TMF semantics as clarified in 1094 section 4.1.2. 1096 10 Security Considerations 1098 This document does not introduce any new security considerations 1099 other than those already noted in [RFC3720]. Consequently, all 1100 the iSCSI-related security text in [RFC3723] is also directly 1101 applicable to this document. 1103 11 IANA Considerations 1105 This draft does not have any specific IANA considerations. 1107 12 References and Bibliography 1109 12.1 Normative References 1111 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, 1112 M., and E. Zeidner, "Internet Small Computer Systems 1113 Interface (iSCSI)", RFC 3720, April 2004. 1115 [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., 1116 and M. Krueger, "Internet Small Computer Systems Interface 1117 (iSCSI) Naming and Discovery", RFC 3721, April 2004. 1119 [SPC3] T10/1416-D, SCSI Primary Commands-3. 1121 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1122 Requirement Levels", March 1997. 1124 12.2 Informative References 1126 [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and 1127 F. Travostino, "Securing Block Storage Protocols over IP", 1128 RFC 3723, April 2004. 1130 [RFC3722] Bakke, M., "String Profile for Internet Small 1131 Computer Systems Interface (iSCSI) Names", RFC 3722, April 1132 2004. 1134 [iSER] Ko, M., Chadalapaka, M., Elzur, U., Shah, H., Thaler, 1135 P., J. Hufferd, "iSCSI Extensions for RDMA", IETF Internet 1136 Draft draft-ietf-ips-iser-04.txt (work in progress), June 1137 2005. 1139 [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate 1140 Requirement Levels", BCP 14, RFC 2119, March 1997. 1142 [SAM2] ANSI INCITS 366-2003, SCSI Architecture Model-2 (SAM- 1143 2). 1145 [SAM3] ANSI INCITS 402-2005, SCSI Architecture Model-3 (SAM- 1146 3). 1148 [SAM4] T10 Project: 1683-D, SCSI Architecture Model-4 (SAM- 1149 4), Work in Progress. 1151 13 Editor's Address 1153 Mallikarjun Chadalapaka 1154 Hewlett-Packard Company 1155 8000 Foothills Blvd. 1156 Roseville, CA 95747-5668, USA 1157 Phone: +1-916-785-5621 1158 E-mail: cbm@rose.hp.com 1160 14 Acknowledgements 1162 The IP Storage (ips) Working Group in the Transport Area of 1163 IETF has been responsible for defining the iSCSI protocol 1164 (apart from a host of other relevant IP Storage protocols). 1165 The editor acknowledges the contributions of the entire 1166 working group. 1168 The following individuals directly contributed to identifying 1169 [RFC3720] issues and/or suggesting resolutions to the issues 1170 clarified in this document: David Black (REPORT LUNS/overflow 1171 semantics, ACA semantics, TMF semantics), Gwendal Grignou 1172 (TMF scope), Mike Ko (digest error handling for Asynchronous 1173 Message), Dmitry Fomichev (reserved ITT), Bill Studenmund 1174 (residual handling, discovery semantics), Ken Sandars 1175 (discovery semantics), Bob Russell (discovery semantics), 1176 Julian Satran (discovery semantics, TMF semantics), Rob 1177 Elliott (T10 liaison, R2T ordering), Joseph Pittman(TMF 1178 scope), Somesh Gupta (multi-task abort semantics), Eddy 1179 Quicksall (message error checking), Paul Koning (message 1180 error checking). This document benefited from all these 1181 contributions. 1183 15 Full Copyright Statement 1185 Copyright (C) The IETF Trust (2007). This document is 1186 subject to the rights, licenses and restrictions contained in 1187 BCP 78, and except as set forth therein, the authors retain 1188 all their rights. 1190 This document and the information contained herein are 1191 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 1192 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 1193 THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET 1194 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1195 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 1196 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1197 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1198 PARTICULAR PURPOSE. 1200 16 Intellectual Property Statement 1202 The IETF takes no position regarding the validity or scope of 1203 any Intellectual Property Rights or other rights that might 1204 be claimed to pertain to the implementation or use of the 1205 technology described in this document or the extent to which 1206 any license under such rights might or might not be 1207 available; nor does it represent that it has made any 1208 independent effort to identify any such rights. Information 1209 on the procedures with respect to rights in RFC documents can 1210 be found in BCP 78 and BCP 79. 1212 Copies of IPR disclosures made to the IETF Secretariat and 1213 any assurances of licenses to be made available, or the 1214 result of an attempt made to obtain a general license or 1215 permission for the use of such proprietary rights by 1216 implementers or users of this specification can be obtained 1217 from the IETF on-line IPR repository at 1218 http://www.ietf.org/ipr. 1220 The IETF invites any interested party to bring to its 1221 attention any copyrights, patents or patent applications, or 1222 other proprietary rights that may cover technology that may 1223 be required to implement this standard. Please address the 1224 information to the IETF at ietf-ipr@ietf.org.