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