idnits 2.17.1 draft-hellwig-nfsv4-scsi-layout-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2014) is 3467 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5661 (Obsoleted by RFC 8881) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 C. Hellwig 3 Internet-Draft October 23, 2014 4 Intended status: Informational 5 Expires: April 26, 2015 7 Parallel NFS (pNFS) SCSI Layout 8 draft-hellwig-nfsv4-scsi-layout-00.txt 10 Abstract 12 Parallel NFS (pNFS) extends Network File Sharing version 4 (RFC5661) 13 to allow clients to directly access file data on the storage used by 14 the NFSv4 server. This ability to bypass the server for data access 15 can increase both performance and parallelism, but requires 16 additional client functionality for data access, some of which is 17 dependent on the class of storage used. The main pNFS operations 18 document specifies storage-class-independent extensions to NFS, the 19 pNFS Block/Volume Layout (RFC5663) specifies the additional 20 extensions for use of pNFS with block-and volume-based storage, while 21 this document provides extensions to the pNFS Block/Volume Layout 22 document to provide reliable fencing and better device 23 discoverability for SCSI based shared storage devices. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 26, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Conventions Used in This Document . . . . . . . . . . . . 3 62 1.3. General Definitions . . . . . . . . . . . . . . . . . . . 3 63 1.4. Code Components Licensing Notice . . . . . . . . . . . . . 4 64 1.5. XDR Description . . . . . . . . . . . . . . . . . . . . . 4 65 2. SCSI Layout Description . . . . . . . . . . . . . . . . . . . 5 66 2.1. GETDEVICEINFO . . . . . . . . . . . . . . . . . . . . . . 7 67 2.1.1. Model . . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.1.2. Volume Identification . . . . . . . . . . . . . . . . 7 69 2.1.3. Volume Topology . . . . . . . . . . . . . . . . . . . 8 70 2.2. Client Fencing . . . . . . . . . . . . . . . . . . . . . . 10 71 2.2.1. PRs - Key Generation . . . . . . . . . . . . . . . . . 10 72 2.2.2. PRs - MDS Registration and Reservation . . . . . . . . 10 73 2.2.3. PRs - Client Registration . . . . . . . . . . . . . . 11 74 2.2.4. PRs - Fencing Action . . . . . . . . . . . . . . . . . 11 75 2.2.5. Client Recovery After a Fence Action . . . . . . . . . 11 76 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 5. Normative References . . . . . . . . . . . . . . . . . . . . . 12 79 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 80 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 13 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 In the parallel Network File System (pNFS), the metadata server 86 returns Layout Type structures that describe where file data is 87 located. There are different Layout Types for different storage 88 systems and methods of arranging data on storage devices. This 89 document extends the pNFS Block/Volume Layout [RFC5663] with a closer 90 integration into the the SCSI Architecture Model ([SAM-4]) to provide 91 a generic fencing method and more scalable device discovery. 93 1.1. Scope 95 This document only specifies an updated version of the layout- 96 specific GETDEVICEINFO XDR response, and a new mandatory fencing 97 method for SCSI devices, but refers to [RFC5663] for the basic 98 principle of operation, as well as the layout specific XDR data 99 structures for the LAYOUTGET and LAYOUTCOMMIT operations. This 100 document does not directly interact with [RFC6688], although the 101 mechanisms described in this document also archive the goals of 102 [RFC6688], and do so in a more robust fashion that does not depend on 103 the cooperation of the systems involved. Thus, the mechanisms 104 specified in [RFC6688] are not necessary for a pNFS SCSI layout type 105 implementation. 107 1.2. Conventions Used in This Document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 1.3. General Definitions 115 The following definitions are provided for the purpose of providing 116 an appropriate context for the reader. 118 Byte This document defines a byte as an octet, i.e., a datum exactly 119 8 bits in length. 121 Client The "client" is the entity that accesses the NFS server's 122 resources. The client may be an application that contains the 123 logic to access the NFS server directly. The client may also be 124 the traditional operating system client that provides remote file 125 system services for a set of applications. 127 Server The "server" is the entity responsible for coordinating 128 client access to a set of file systems and is identified by a 129 server owner. 131 Fencing "Fencing" is the action to prevent an individual client from 132 accessing a resource. 134 1.4. Code Components Licensing Notice 136 The external data representation (XDR) description and scripts for 137 extracting the XDR description are Code Components as described in 138 Section 4 of "Legal Provisions Relating to IETF Documents" [LEGAL]. 139 These Code Components are licensed according to the terms of Section 140 4 of "Legal Provisions Relating to IETF Documents". 142 1.5. XDR Description 144 This document contains the XDR [RFC4506] description of the NFSv4.1 145 SCSI layout protocol. The XDR description is embedded in this 146 document in a way that makes it simple for the reader to extract into 147 a ready-to-compile form. The reader can feed this document into the 148 following shell script to produce the machine readable XDR 149 description of the NFSv4.1 SCSI layout: 151 #!/bin/sh 152 grep '^ *///' $* | sed 's?^ */// ??' | sed 's?^ *///$??' 154 That is, if the above script is stored in a file called "extract.sh", 155 and this document is in a file called "spec.txt", then the reader can 156 do: 158 sh extract.sh < spec.txt > flex_files_prot.x 160 The effect of the script is to remove leading white space from each 161 line, plus a sentinel sequence of "///". 163 The embedded XDR file header follows. Subsequent XDR descriptions, 164 with the sentinel sequence are embedded throughout the document. 166 Note that the XDR code contained in this document depends on types 167 from the NFSv4.1 nfs4_prot.x file [RFC5662]. This includes both nfs 168 types that end with a 4, such as offset4, length4, etc., as well as 169 more generic types such as uint32_t and uint64_t. 171 /// /* 172 /// * This code was derived from draft-hellwig-nfsv4-scsi-layout 173 /// * Please reproduce this note if possible. 174 /// */ 175 /// /* 176 /// * Copyright (c) 2010 IETF Trust and the persons identified 177 /// * as the document authors. All rights reserved. 178 /// * 179 /// * Redistribution and use in source and binary forms, with 180 /// * or without modification, are permitted provided that the 181 /// * following conditions are met: 182 /// * 183 /// * - Redistributions of source code must retain the above 184 /// * copyright notice, this list of conditions and the 185 /// * following disclaimer. 186 /// * 187 /// * - Redistributions in binary form must reproduce the above 188 /// * copyright notice, this list of conditions and the 189 /// * following disclaimer in the documentation and/or other 190 /// * materials provided with the distribution. 191 /// * 192 /// * - Neither the name of Internet Society, IETF or IETF 193 /// * Trust, nor the names of specific contributors, may be 194 /// * used to endorse or promote products derived from this 195 /// * software without specific prior written permission. 196 /// * 197 /// * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS 198 /// * AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED 199 /// * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 200 /// * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 201 /// * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO 202 /// * EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE 203 /// * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 204 /// * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 205 /// * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 206 /// * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 207 /// * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF 208 /// * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 209 /// * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING 210 /// * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF 211 /// * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 212 /// */ 213 /// 214 /// /* 215 /// * nfs4_scsi_layout_prot.x 216 /// */ 217 /// 218 /// %#include "nfs4_block_layout_prot.x" 219 /// %#include "nfsv41.h" 220 /// 222 2. SCSI Layout Description 224 The layout4 type is defined in [RFC5662] as follows: 226 enum layouttype4 { 227 LAYOUT4_NFSV4_1_FILES = 1, 228 LAYOUT4_OSD2_OBJECTS = 2, 229 LAYOUT4_BLOCK_VOLUME = 3, 230 LAYOUT4_SCSI = 0x80000005 231 [[RFC Editor: please modify the LAYOUT4_SCSI 232 to be the layouttype assigned by IANA]] 233 }; 235 struct layout_content4 { 236 layouttype4 loc_type; 237 opaque loc_body<>; 238 }; 240 struct layout4 { 241 offset4 lo_offset; 242 length4 lo_length; 243 layoutiomode4 lo_iomode; 244 layout_content4 lo_content; 245 }; 247 This document defines structure associated with the layouttype4 value 248 LAYOUT4_SCSI. [RFC5661] specifies the loc_body structure as an XDR 249 type "opaque". The opaque layout is uninterpreted by the generic 250 pNFS client layers, but obviously must be interpreted by the Layout 251 Type implementation. All structures behind this opaque value are 252 identical to those defined in [RFC5663]. 254 2.1. GETDEVICEINFO 256 /// /* 257 /// * Code sets from SPC-3. 258 /// */ 259 /// enum pnfs_scsi_code_set { 260 /// PS_CODE_SET_BINARY = 1, 261 /// PS_CODE_SET_ASCII = 2, 262 /// PS_CODE_SET_UTF8 = 3 263 /// }; 264 /// 265 /// /* 266 /// * Designator types from taken from SPC-3. 267 /// * 268 /// * Other values are allocated in SPC-3, but not mandatory to 269 /// * implement or aren't logical unit names. 270 /// */ 271 /// enum pnfs_scsi_designator_type { 272 /// PS_DESIGNATOR_EUI64 = 2, 273 /// PS_DESIGNATOR_NAA = 3, 274 /// PS_DESIGNATOR_NAME = 8 275 /// }; 276 /// 277 /// /* 278 /// * Logical unit name + reservation key. 279 /// */ 280 /// struct pnfs_scsi_base_volume_info4 { 281 /// pnfs_scsi_code_set sbv_code_set; 282 /// pnfs_scsi_designator_type sbv_designator_type; 283 /// opaque sbv_lu_name<>; 284 /// uint32_t sbv_pr_key; 285 /// }; 286 /// 288 2.1.1. Model 290 GETDEVICEINFO calls are handled exactly the same way as specified in 291 [RFC5663]. The "pnfs_scsi_volume_type4" data structure returned by 292 the server as the storage-protocol-specific opaque field da_addr_body 293 in the "device_addr4" structure by a successful GETDEVICEINFO 294 operation [RFC5661] is a strict superset of the 295 "pnfs_block_volume_type" structured defined by [RFC5663]. 297 2.1.2. Volume Identification 299 SCSI targets implementing [SPC3] export unique logical unit names for 300 each logical unit through the Device Identification VPD page which 301 can be obtained using the INQUIRY command. This document uses a 302 subset of this information to identify logical units backing pNFS 303 SCSI layouts. It is similar to the "Identification Descriptor Target 304 Descriptor" specified in [SPC3], but limits the allowed values to 305 those that uniquely identify a logical unit. Device Identification 306 VPD page descriptors used to identify logical units for use with pNFS 307 SCSI layouts must adhere to the following restrictions: 309 1. The "ASSOCIATION" must be set to 0 (The DESIGNATOR field is 310 associated with the addressed logical unit). 312 2. The "DESIGNATOR TYPE" must be set to one of three values 313 explicitly listed in the "pnfs_scsi_designator_type" 314 enumerations. 316 The "CODE SET" VPD page field is stored in the "sbv_code_set" field 317 of the "pnfs_scsi_base_volume_info4" structure, the "DESIGNATOR TYPE" 318 is stored in "sbv_designator_type", and the DESIGNATOR is stored in 319 "sbv_designator". Due to the use of a XDR array the "DESIGNATOR 320 LENGTH" field does not need to be set separately. Only certain 321 combinations of "sbv_code_set" and "sbv_designator_type" are valid, 322 please refer to [SPC3] for details, and note that ASCII may be used 323 as the code set for UTF-8 text that does not contain non-ASCII 324 characters. Note that a Device Identification VPD page MAY contain 325 multiple descriptors with the same association, code set and 326 designator type. NFS clients thus MUST iterate the descriptors until 327 a match for "sbv_code_set", "sbv_designator_type" and 328 "sbv_designator" is found, or until the end of VPD page. 330 Additionally the server returns a Persistent Reservation key in the 331 "sbv_pr_key" field. See Section 2.2 for more details on the use of 332 Persistent Reservations. 334 2.1.3. Volume Topology 336 The pNFS SCSI server volume topology is expressed as an arbitrary 337 combination of base volume types enumerated in the following data 338 structures. The individual components of the topology are contained 339 in an array and components may refer to other components by using 340 array indices. 342 /// enum pnfs_scsi_volume_type4 { 343 /// PNFS_SCSI_VOLUME_SIMPLE = 344 /// PNFS_BLOCK_VOLUME_SIMPLE , /* invalid */ 345 /// PNFS_SCSI_VOLUME_SLICE = /* see RFC5663 */ 346 /// PNFS_BLOCK_VOLUME_SLICE, 347 /// PNFS_SCSI_VOLUME_CONCAT = /* see RFC5663 */ 348 /// PNFS_BLOCK_VOLUME_CONCAT, 349 /// PNFS_SCSI_VOLUME_STRIPE = /* see RFC5663 */ 350 /// PNFS_BLOCK_VOLUME_STRIPE, 351 /// PNFS_SCSI_VOLUME_BASE = 4 /* SCSI LU */ 352 /// }; 353 /// 355 /// 356 /// union pnfs_scsi_volume4 switch (pnfs_scsi_volume_type4 type) { 357 /// case PNFS_SCSI_VOLUME_SIMPLE: 358 /// pnfs_block_simple_volume_info4 sv_simple_info; 359 /// case PNFS_SCSI_VOLUME_SLICE: 360 /// pnfs_block_slice_volume_info4 sv_slice_info; 361 /// case PNFS_SCSI_VOLUME_CONCAT: 362 /// pnfs_block_concat_volume_info4 sv_concat_info; 363 /// case PNFS_SCSI_VOLUME_STRIPE: 364 /// pnfs_block_stripe_volume_info4 sv_stripe_info; 365 /// case PNFS_SCSI_VOLUME_BASE: 366 /// pnfs_scsi_base_volume_info4 sv_base_info; 367 /// }; 368 /// 370 /// /* scsi layout specific type for da_addr_body */ 371 /// struct pnfs_scsi_deviceaddr4 { 372 /// pnfs_scsi_volume4 sda_volumes<>; /* array of volumes */ 373 /// }; 374 /// 376 All rules for ordering and formation of a "pnfs_scsi_deviceaddr4" 377 structure are identical for those of a "pnfs_block_deviceaddr4" 378 structure in [RFC5663], except that the new 379 pnfs_scsi_base_volume_info4 PNFS_SCSI_VOLUME_BASE case is used in 380 place of the pnfs_block_simple_volume_info4 PNFS_BLOCK_VOLUME_SIMPLE 381 case as the base structure. A PNFS_BLOCK_VOLUME_SIMPLE element MUST 382 NOT be referenced by a pnfs_scsi_deviceaddr4, but is preserved for 383 XDR level compatibility. 385 2.2. Client Fencing 387 The pNFS block protocol must handle situations in which a system 388 failure, typically a network connectivity issue, requires the server 389 to unilaterally revoke extents from one client in order to transfer 390 the extents to another client. The pNFS server implementation MUST 391 ensure that when resources are transferred to another client, they 392 are not used by the client originally owning them, and this must be 393 ensured against any possible combination of partitions and delays 394 among all of the participants to the protocol (server, storage and 395 client). [RFC5663] suggest to either use LUN masking or cooperative 396 clients. The first implementation requires the server and the 397 storage device to have common notation of a client, which is 398 impossible when the NFS and storage connection don't share a network, 399 and requires a non-standardized control protocol between the MDS and 400 the storage device. The second implementation relies on a 401 cooperative client, which is not robust. 403 Instead this document specifies a new SCSI-specific fencing protocol 404 using Persistent Reservations (PRs), similar to the fencing method 405 used by existing shared disk file systems. By placing a PR of type 406 "Exclusive Access - All Registrants" on each SCSI logical unit 407 exported to pNFS clients the MDS prevents access from any client that 408 does not have an outstanding device device ID that gives the client a 409 reservation key to access to logical unit, and allows the MDS to 410 revoke access to the logic unit at any time. 412 2.2.1. PRs - Key Generation 414 To allow fencing individual systems, each systems MUST use a unique 415 Persistent Reservation key. [SPC3] does not specify a way to 416 generate keys. This document assigns the burden to generate unique 417 keys to the MDS, which MUST generate a key for itself before 418 exporting a volume, and one for each client that access a volume. 419 The MDS MAY either generate a key for each client that accesses logic 420 units exported by the MDS, or to generate a key for each [logical 421 unit, client] combination. In case of a single key per client, the 422 MDS needs to be aware of the per-client fencing granularity. 424 2.2.2. PRs - MDS Registration and Reservation 426 Before returning a PNFS_SCSI_VOLUME_BASE volume to the client, the 427 MDS needs to prepare the volume for fencing using PRs. This is done 428 by registering the reservation generated for the MDS with the device 429 using the "PERSISTENT RESERVE OUT" command with a service action of 430 "REGISTER", followed by a "PERSISTENT RESERVE OUT" command, with a 431 service action of "RESERVE" and the type field set to 8h (Exclusive 432 Access - All Registrants). To make sure all I_T nexus are 433 registered, the MDS SHOULD set the "All Target Ports" (ALL_TG_PT) bit 434 when registering the key, or otherwise ensure the registration is 435 performed for each initiator port. 437 2.2.3. PRs - Client Registration 439 After a successful GETDEVICEINFO operation the client MUST register 440 the registration key returned in sbv_pr_key with the storage device 441 by issuing a "PERSISTENT RESERVE OUT" command with a service action 442 of REGISTER with the "SERVICE ACTION RESERVATION KEY" set to the 443 reservation key returned in sbv_pr_key. To make sure all I_T nexus 444 are registered, the client SHOULD set the "All Target Ports" 445 (ALL_TG_PT) bit when registering the key, or otherwise ensure the 446 registration is performed for each initiator port. 448 When a client stops using a device earlier returned by GETDEVICEINFO 449 it MUST unregister the earlier registered key by issuing a 450 "PERSISTENT RESERVE OUT" command with a service action of "REGISTER" 451 with the "RESERVATION KEY" set to the earlier registered reservation 452 key. 454 2.2.4. PRs - Fencing Action 456 In case of a non-responding client the MDS MUST fence the client by 457 issuing a "PERSISTENT RESERVE OUT" command with the service action 458 set to "PREEMPT" or "PREEMPT AND ABORT", the reservation key field 459 set to the server's reservation key, and the service action 460 reservation key field set to the reservation key associated with the 461 non-responding client, and the type field set to 8h (Exclusive Access 462 - All Registrants). 464 After the MDS preempted a client, all client I/O to the logical unit 465 will fail. The client should at this point return any layout that 466 refers to the device ID that poіnts to the logical unit. Note 467 that the client can distinguish I/O errors due to fencing from other 468 errors based on the "RESERVATION CONFLICT" status. Refer to [SPC3] 469 for details. 471 2.2.5. Client Recovery After a Fence Action 473 A client that detects I/O errors on the storage devices MUST commit 474 through the MDS, return all outstanding layouts and forget any opened 475 devices. Any device returned by a future LAYOUTGET will contain a 476 new reservation key that can be used to gain access to the storage 477 device. 479 3. Security Considerations 481 The security considerations in [RFC5663] apply to this document as 482 well. 484 4. IANA Considerations 486 IANA is requested to assign a new pNFS layout type in the pNFS Layout 487 Types Registry as follows (the value 5 is suggested): Layout Type 488 Name: LAYOUT4_SCSI Value: 0x00000005 RFC: RFCTBD10 How: L (new layout 489 type) Minor Versions: 1 491 5. Normative References 493 [LEGAL] IETF Trust, "Legal Provisions Relating to IETF Documents", 494 November 2008, . 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", March 1997. 500 [RFC4506] Eisler, M., "XDR: External Data Representation Standard", 501 STD 67, RFC 4506, May 2006. 503 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 504 "Network File System (NFS) Version 4 Minor Version 1 505 Protocol", RFC 5661, January 2010. 507 [RFC5662] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 508 "Network File System (NFS) Version 4 Minor Version 1 509 External Data Representation Standard (XDR) Description", 510 RFC 5662, January 2010. 512 [RFC5663] Black, D., Ed., Fridella, S., Ed., and J. Glasgow, Ed., 513 "Parallel NFS (pNFS) Block/Volume Layout", RFC 5663, 514 January 2010. 516 [RFC6688] Black, D., Ed., Glasgow, J., and S. Faibish, "Parallel NFS 517 (pNFS) Block Disk Protection", RFC 6688, July 2012. 519 [SAM-4] INCITS Technical Committee T10, "SCSI Architecture Model - 520 4 (SAM-4)", ANSI INCITS 447-2008, ISO/IEC 14776-414, 2008. 522 [SPC3] INCITS Technical Committee T10, "SCSI Primary Commands-3", 523 ANSI INCITS 408-2005, ISO/IEC 14776-453, 2005. 525 Appendix A. Acknowledgments 527 David Black, Robert Elliott and Tom Haynes provided a throughout 528 review of early drafts of this document, and their input lead to the 529 current form of the document. 531 Appendix B. RFC Editor Notes 533 [RFC Editor: please remove this section prior to publishing this 534 document as an RFC] 536 [RFC Editor: prior to publishing this document as an RFC, please 537 replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the 538 RFC number of this document] 540 Author's Address 542 Christoph Hellwig 544 Email: hch@lst.de