idnits 2.17.1 draft-faibish-nfsv4-pnfs-access-permissions-check-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 == Line 340 has weird spacing: '...eviceid lor...' == Line 402 has weird spacing: '...eviceid lor...' == Unrecognized Status in 'Intended status: draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (October 18, 2009) is 5304 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'LEGAL' is defined on line 540, but no explicit reference was found in the text == Unused Reference: 'XDR' is defined on line 559, but no explicit reference was found in the text == Unused Reference: 'MPFS' is defined on line 564, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'LEGAL' Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 Working Group S. Faibish 3 Internet-Draft EMC Corporation 4 Intended status: draft D. Black 5 Expires: April 18, 2010 EMC Corporation 6 M. Eisler 7 NetApp 8 October 18, 2009 10 pNFS Access Permissions Check 11 draft-faibish-nfsv4-pnfs-access-permissions-check-00 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on April 18, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document describe an extension to pNFS protocol addressing a gap 50 related to the access permission checks to data servers used by the 51 MDS in layouts sent to the clients. The draft addresses both the 52 client access permission checks as well as the MDS access permissions 53 to the data servers. The draft will address new errors related to 54 access permission denial to devices included in valid pNFS layouts. 55 The draft will also address the case when clients request direct NFS 56 access to the MDS and the MDS has no permission to access some of the 57 data servers included in valid layouts. 59 Table of Contents 61 1. Introduction...................................................3 62 1.1. Example...................................................4 63 1.2. Issues with the current pNFS protocol.....................5 64 1.2.1. Client access permission denial to SD................6 65 1.2.2. MDS access permission denial to SD...................6 66 1.2.3. Implied Requirement..................................7 67 2. Conventions used in this document..............................7 68 3. Description of the proposed approaches to solution.............7 69 3.1. Simple implementation adding new LAYOUTRETURN error code..8 70 3.1.1. ARGUMENT.............................................8 71 3.1.2. RESULT...............................................8 72 3.1.3. Description..........................................8 73 3.2. Implementation using a new layoutreturn_type4.............9 74 3.2.1. ARGUMENT.............................................9 75 3.2.2. RESULT..............................................10 76 3.2.3. New LAYOUTRETURN type description...................10 77 4. Reporting the permission denial...............................10 78 4.1. Permission denied to client at mount time................10 79 4.2. Permission denied to the client at I/O time..............11 80 4.3. Permission denied to MDS server at I/O time..............12 81 5. Security Considerations.......................................12 82 6. IANA Considerations...........................................12 83 7. Conclusions...................................................12 84 8. References....................................................13 85 8.1. Normative References.....................................13 86 8.2. Informative References...................................13 87 9. Acknowledgments...............................................13 88 Authors' Addresses...............................................14 90 1. Introduction 92 Figure 1 shows the overall architecture of a Parallel NFS (pNFS) 93 system: 95 +-----------+ 96 |+-----------+ +-----------+ 97 ||+-----------+ | | 98 ||| | NFSv4.1 + pNFS | | 99 +|| Clients |<------------------------------>| MDS | 100 +| | | | 101 +-----------+ | | 102 ||| +-----------+ 103 ||| | 104 ||| | 105 ||| Storage +-----------+ | 106 ||| Protocol |+-----------+ | 107 ||+----------------||+-----------+ Control | 108 |+-----------------||| | Protocol | 109 +------------------+|| Storage |------------+ 110 +| Devices | 111 +-----------+ 113 Figure 1 pNFS Architecture 115 There is a possible gap in the pNFS protocol regarding permissions of 116 access to storage devices in the cases of a client that has no 117 permission to access a storage device (SD) included in a valid layout 118 sent by the MDS server. Some consider this gap an optimization or an 119 implementation detail but the permission denials can defeat the 120 performance scalability value of pNFS and to possible opportunities 121 of unreported errors. From the pNFS protocol perspective there is no 122 error mechanism to inform a system administrator that a client 123 doesn't have the access permission to a storage device at mount time 124 nor at I/O time. This is also the case with the MDS that doesn't have 125 access permission to some storage devices and it is asked by a client 126 to perform I/O to the device on behalf of the client. In this 127 document storage devices mean also data servers and storage severs 128 which could refer to file, block or object storage. 130 On one hand looking at the block layout if the MDS doesn't see the 131 storage devices/LUNs it cannot mount the pNFS file system, of course 132 it cannot allow a client to mount that FSID and an error is logged by 133 the MDS server. If the pNFS block server can access all the storage 134 devices/LUNs but the client doesn't have the access permission to 135 some storage devices/LUNs at mount time the client will mount as 136 NFSV4.1 without pNFS support (fallback to NFS) without any 137 error/reason for the fall back. If the client doesn't have access 138 permission to all the storage devices it will log an error at the 139 client without any explanation of the reason of mounting NFSV4.1 140 without pNFS support. 142 This is true for file and object layout pNFS clients regardless if 143 the MDS has permission to access the storage devices or not. On the 144 other hand, for the file and object layouts there is no similar error 145 mechanism to report the case when the client or the server cannot 146 access a storage device and there is no CB for access permission 147 check. The only fallback is a request for re-direct by the MDS server 148 as storage device is inaccessible assuming that the MDS server has 149 access to the storage device and it can serve the I/O to the client 150 still without logging an error at least not at mount time. This 151 assumption is weaker than in the case of the block layout that cannot 152 allow to mount a FSID to which it has no access permission. 154 1.1. Example 156 A typical usecase is when a new storage device is added and all the 157 pNFS clients (1000s of them) have no access permission to the new 158 storage device. From this time on all the I/Os to the new storage 159 device will be served by the MDS server creating a performance and 160 scalability bottleneck that is difficult to detect. 162 A better approach to address this issue is to report the access 163 failure before the client attempt to issue any I/Os to the MDS server 164 rather than the MDS trying to diagnose the performance problem caused 165 by client I/O using NFS path and not using the pNFS layout. In the 166 current pNFS protocol a client cannot detect this situation at mount 167 time in cases of complex mountpoint structures and we can perhaps 168 only address the error for the root/top of the mount structure 169 assuming we are only referring to pNFS capable clients. See section 170 1.2.1 for detailed example. 172 The intention of this draft is to introduce a new access permission 173 check and error access permission denial report mechanism at both 174 server and client to address the above issues. 176 One of the problems may be the fact that there is no mention in the 177 pNFS spec to address the data protocol between MDS and storage 178 devices, except for the block layout driver in which case the MDS 179 cannot itself mount a pNFS file system due to access permission 180 issue. In order for the MDS server to export a filesystem as NFSV4.1 181 filesystem for pNFS clients access it is mandatory for the MDS to 182 have access permission to all the storage devices/LUNs for that 183 filesystem as a pre-condition for the mount. In the case that there 184 is any access permission issue the filesystem cannot be mounted by 185 the MDS and an error is sent to the MDS server log. 187 On the other hand for file and object pNFS layout MDS servers there 188 is no requirement in the spec to check access permission to all the 189 storage devices even when the NFSV4.1 filesystem is exported to the 190 pNFS clients. In fact an MDS that accesses the storage devices is 191 considered an unhealthy pNFS server except for the case when a pNFS 192 client fall back to NFS and requests the MDS server to perform an I/O 193 on his behalf. At that time the MDS must access the storage server in 194 order to perform the I/O. It is then possible that the MDS I/O to the 195 storage device fails due to access permission denial in which case 196 the MDS will send a error to the client and the client I/O fails. 198 There is no error report mechanism in the pNFS protocol for this type 199 of error. Even if we correct the access permission issue the 200 introduction of a new error reporting mechanism at I/O time for both 201 server and client can be problematic as it may be too chatty. We 202 propose to introduce a new error case but leave the error reporting 203 mechanism at I/O time OPTIONAL or an optimization to the latitude of 204 the server and client implementation. 206 Although the change to the protocol is delicate logging some kind of 207 warning at the client might be appropriate to be recommended as an 208 implementation option on the client to reduce chattiness. 210 1.2. Issues with the current pNFS protocol 212 Scenario of Interest: Client expects to be able to use pNFS (e.g., 213 use -pnfs switch to mount command, or similar), but one or more 214 devices are inaccessible. This discussion does not apply to a client 215 that doesn't care (e.g., uses pNFS to optimize if available, but is 216 ok if all of its access is via the main NFS server). 218 Desired client behavior: Client gets entire device list for mount 219 point from server and checks it as part of the mount operation (or at 220 whatever point it first realizes that it expects to use pNFS). 222 Missing piece of protocol: Client has no obvious way to report an 223 inaccessible device to the server. 225 1.2.1. Client access permission denial to SD 227 A client doesn't communicate to the MDS server that the client's 228 access to a storage device is denied as a result of an access 229 permission issue. When the pNFS server grants a layout to the client, 230 it assumes the client can access the storage devices (files, luns, or 231 objects). The server cannot check this because the server cannot 232 issue I/Os via the client and because connectivity is not transitive 233 - the client may have good network connectivity to the MDS, the MDS 234 may have good storage connectivity to the storage devices, but 235 something in the storage network prevents the client from talking to 236 one or more of the storage devices. This could be a network mis- 237 configuration or failure, and it's a possible scenario for all pNFS 238 layout types. 240 The access permission problem cannot be reported at mount time for a 241 number of reasons. Reporting the permission problem at mount time has 242 some difficulties. First, the MDS pNFS server doesn't know that the 243 client can even mount with pNFS support. Second, the MDS NFS server 244 doesn't know that the client is mounting the NFS filesystem (there is 245 no separate mount protocol in NFSv4). Third, the MDS server cannot 246 know if the client mounts say, "/", and the file systems below "/" 247 have pNFS capabilities, but refer to different storage devices. Or 248 the client mounts say "/a/b/c/d", and d is in a pNFS capable volume. 249 But the client is going actually do its I/O to "e/f/g/h/i/j/k", and k 250 is either no pNFS capable, or it is, but uses a storage device that 251 differs from d. 253 1.2.2. MDS access permission denial to SD 255 The current pNFS server protocol doesn't mandatory require to access 256 the storage devices and there is only a control protocol (Fig. 1) 257 between the MDS and the storage devices but there is no specific data 258 access protocol between the MDS and the SDs. Although the MDS doesn't 259 check permissions it is assumed that at the configuration is correct 260 when the storage devices are initially configured and the pNFS 261 filesystem is mounted on the MDS server. It is possible that the 262 administrator checks the MDS access permission to all the SD during 263 the configuration. The problem may not exist at the time of the 264 initial mount of the pNFS filesystem but can surface when a new SD is 265 added to the pool of SDs. If the MDS tries to do successful I/Os to 266 the new added SD before including it in the layout to pNFS clients 267 will avoid this set of problems. The pNFS specification does not 268 address the data access protocol between the MDS and the storage 269 devices. 271 1.2.3. Implied Requirement 273 Metadata server SHOULD NOT use devices in pNFS layouts that are not 274 accessible to the MDS (or to clients if the MDS has any means of 275 determining this). 277 2. Conventions used in this document 279 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 280 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 281 document are to be interpreted as described in RFC-2119 [RFC2119]. 283 3. Description of the proposed approaches to solution 285 A simple possible approach is to address the gap in the protocol by 286 simply adding a new LAYOUTRETURN type and a new error case to 287 LAYOUTRETURN. In the case that the pNFS client has a valid layout on 288 a file but cannot perform I/O to a SD due to access permission 289 denial, the client will fall back the I/O to the MDS NFS server. 290 Before the client sends the I/O to the NFS server it will send a 291 LAYOUTRETURN command for the purpose of avoiding unnecessary MDS 292 CB_LAYOUTRECALL operations in the future. The client will send the 293 LAYOUTRETURN operation for the layouts corresponding to the 294 inaccessible SD and include a new error reporting that the reason of 295 the fall back to the NFS server is access permission denial to the 296 specific deviceid4. The client may return disjoint regions of the 297 file by using multiple LAYOUTRETURN operations within a single 298 COMPOUND operation. The client will include NFS4ERR_DEVICE_PERM_DENY 299 in the new LAYOUTRETURN operation. 301 LAYOUTRETURN at FSID scope seems like the best simple choice 302 available. Alternatively we can introduce a new LAYOUTRETURN type 303 that is LAYOUT4_RET_REC_FSID_NO_ACCESS, i.e., return all layouts for 304 this FSID and tell the server that the reason for the return is a 305 connectivity issue. In order to differentiate the permission issue 306 from a real connectivity issue the solution will require the client 307 to do two LAYOUTRETURN operations to deal with servers that don't 308 understand the new type. The two LAYOUTRETURN operations happen once 309 per client using LAYOUT4_RET_REC_FSID_NO_ACCESS and only in an error 310 case followed by a second operation for "FSID" in case the first one 311 wasn't understood. 313 3.1. Simple implementation adding new LAYOUTRETURN error code 315 3.1.1. ARGUMENT 317 When the LAYOUTRETURN operation specifies a LAYOUTRETURN4_FILE_return 318 type, then the layoutreturn_file4 data structure specifies the region 319 of the file layout that is no longer needed by the client. We will 320 modify the layoutreturn_file4 changing the opaque "lrf_body" field of 321 the "layoutreturn_file4" data structure to include the deviceid with 322 access permission error. Alternative, more complex, add the deviceid 323 to the layoutreturn_type4. 325 struct layoutreturn_file4 { 326 offset4 lrf_offset; 327 length4 lrf_length; 328 stateid4 lrf_stateid; 329 deviceid4 lrf_deviceid; 330 /* layouttype4 specific data */ 331 opaque lrf_body; 332 }; 334 3.1.2. RESULT 336 union LAYOUTRETURN4res switch (nfsstat4 lorr_status) { 337 case NFS4_OK: 338 layoutreturn_stateid lorr_stateid; 339 case NFS4ERR_DEVICE_PERM_DENY: 340 layoutreturn_deviceid lorr_deviceid; 341 default: 342 void; 343 }; 345 3.1.3. Description 347 This solution will add a new error case to LAYOUTRETURN. The 348 implementation will use LAYOUTRETURN when FSID is sent to the client. 349 When the client fails an I/O as a result of access permission denial 350 it will send a LAYOUTRETURN operation to the MDS server with new 351 error NFS4ERR_DEVICE_PERM_DENY specifying the deviceid4 with 352 permission denial. 354 When the server receives this error it can OPTIONALLY log an error to 355 the syslog and perform a access performance check to the SD expecting 356 that the client will fall back the I/O to the MDS. If the permission 357 check of the server fails the NFS4ERR_DEVICE_PERM_DENY will be sent 358 to the syslog. 360 3.2. Implementation using a new layoutreturn_type4 362 In this section we will define the usecase addressed by this 363 implementation. 365 3.2.1. ARGUMENT 367 /* Constants used for new LAYOUTRETURN and CB_LAYOUTRECALL */ 368 const LAYOUT4_RET_REC_FILE = 1; 369 const LAYOUT4_RET_REC_FSID = 2; 370 const LAYOUT4_RET_REC_ALL = 3; 371 const LAYOUT4_RET_REC_DEVICE = 4; 373 enum layoutreturn_type4 { 374 LAYOUTRETURN4_DEVICE = LAYOUT4_RET_REC_DEVICE_NO_ACCESS, 375 LAYOUTRETURN4_FILE = LAYOUT4_RET_REC_FILE, 376 LAYOUTRETURN4_FSID = LAYOUT4_RET_REC_FSID, 377 LAYOUTRETURN4_ALL = LAYOUT4_RET_REC_ALL 378 }; 380 struct layoutreturn_device4 { 381 offset4 lrf_offset; 382 length4 lrf_length; 383 stateid4 lrf_stateid; 384 deviceid4 lrf_deviceid; 385 /* layouttype4 specific data */ 386 opaque lrf_body<>; 387 }; 389 union layoutreturn4 switch(layoutreturn_type4 lr_returntype) { 390 case LAYOUTRETURN4_DEVICE: 391 layoutreturn_device4 lr_layout; 392 default: 393 void; 394 }; 396 3.2.2. RESULT 398 union LAYOUTRETURN4res switch (nfsstat4 lorr_status) { 399 case NFS4_OK: 400 layoutreturn_stateid lorr_stateid; 401 case NFS4ERR_DEVICE_PERM_DENY: 402 layoutreturn_deviceid lorr_deviceid; 403 default: 404 void; 405 }; 406 3.2.3. New LAYOUTRETURN type description 408 We will use a new LAYOUTRETURN layoutreturn_type4, let's call it 409 LAYOUT4_RET_REC_DEVICE_NO_ACCESS, in which case the client returns 410 all layouts for this DEVICE and OPTIONAL for the FSID and tell the 411 server that the reason for the return is a connectivity issue. The 412 same stateid may be used or in order to report a new error client 413 will force a new stateid. We will also add the operation to report a 414 new error NFS4ERR_DEVICE_PERM_DENY. 416 To address the backward compatibility may require a client to do two 417 layout return operations to deal with servers that don't understand 418 the new layoutreturn_type4. If the server doesn't understand the new 419 layoutreturn_type4, then the server will come back with an error 420 code. The client needs to do a FSID return and remember that this 421 server doesn't understand the new return type. This assumes that the 422 client is sufficient disrupted by the connectivity problem to the 423 point it decided to drop all layouts for the filesystem (FSID), which 424 matches the failure case of client data server access permission 425 deny. Alternatively when the server receives a new stateid it will 426 check the error or issue an CB_LAYOUTRECALL to get the error. 428 4. Reporting the permission denial 430 4.1. Permission denied to client at mount time 432 The most suitable time for the client reporting the permission denial 433 by a data server is at the mount time. This would be the preferred 434 way to address the issue but it is not possible with the current 435 protocol for several reasons: If the server initiates the request, 436 MDS doesn't know if the client wants to use pNFS or NFS. If the 437 client is the initiator of the error the is mounting the pNFS 438 filesystem knowing that it will use pNFS for access the client 439 doesn't specifically request pNFS. 441 The solution will be to use a special tag -pnfs or a switch to 442 mount/syscall. To the latest issue the client cannot explicitly 443 request pNFS as it needs first to discover that the server is 444 supporting pNFS. In order to address this issue the client needs to 445 send a request at mount time to the server as part of the initial 446 handshake. There is no reportable error of the client to cope with 447 this currently. 449 The client makes a file access and it finds that the NFS server is 450 pNFS capable it will request a LAYOUTGET command and if the NFS 451 server doesn't accept and returns an error the client will request 452 access using plain NFS. The client will decide if this is an error or 453 not. In the case that the LAYOUTGET command succeeded the client may 454 still ask the MDS to deliver the I/O. So, inherently the client has 455 to query the MDS access permissions to all the DS that are used in 456 the layout send to the client before putting the device into a 457 layout. The pNFS protocol doesn't require the MDS to check access 458 permission to the devices that are included in the layout. It is 459 assumed that the MDS has permission access to all the devices it 460 includes in the layout without any checks. 462 If the MDS doesn't know if it has access or not it shouldn't put that 463 device in the layout granted to clients to prevent cases when the 464 client ask the I/O using plain NFS from the MDS. If the MDS doesn't 465 have permission access to a data server it will send an error to the 466 client and the I/O will fail. Based on the above behavior the best 467 time to check is at the time when the initial configuration of the 468 pNFS filesystem is done. Currently the pNFS spec states that a client 469 can write through or read from the MDS, whether it has a layout or 470 not or it does not support pNFS assuming that the MDS has permission 471 access to all the data servers. We propose to make this implicit 472 recommendation explicit. 474 4.2. Permission denied to the client at I/O time 476 In this case when the pNFS capable client receives a valid layout 477 from the pNFS capable MDS server and due to access permission denial 478 to some devices cannot write to the storage devices, it will fall 479 back to the NFS server for the I/O. There is no error logged by the 480 client nor sent back to the MDS server mentioning the reason for the 481 fallback. As a result there is no way to fix the configuration 482 problem until the client unmounts the pNFS filesystem. And 483 potentially if there is no permission check at mount time even the 484 remount will not detect the problem. Moreover as the MDS server never 485 checks access permission to the storage devices the MDS will not be 486 able to perform the I/O unless the MDS is also a storage device 487 itself, in which case the I/O will fail without any error mentioning 488 permission denial. One option is for the MDS to send a LAYOUTRETURN 489 with FSID_PERM_CHECK in the case when the a pNFS client request the 490 MDS to write an I/O to one of the devices from a layout sent to the 491 client by the MDS the MDS will check the error and send a CB request 492 for FSID_PERM_CHECK. 494 4.3. Permission denied to MDS server at I/O time 496 In case when the client holding a valid layout requests the NFS 497 server to execute the I/O the MDS will have to access the data 498 server/device that the client requested to write to and gets an 499 access permission denial from the storage device, the MDS cannot 500 perform the I/O and will return an error to the client. In this case 501 the client I/O will fail indefinitely and there no error information 502 about the reason of the failure related to permission denial to data 503 servers. The client has no means to communicate to the server the 504 permission denial as there is no check and error case. To address 505 this case a new error code will be added to the LAYOUTRETURN call 506 mentioning DEVICE_PERM_DENY and the MDS will send an error to the 507 client NFS4ERR_PERM_DENY. An additional option is to send a CB to the 508 client requesting permission access check and on failure the MDS will 509 log an error NFS4ERR_DEVICE_UNACCESSIBLE to inform the admin to 510 correct the problem. On receiving the permission check the client 511 will send the DS a GETDEVICEINFO and report NFS4ERR_DEVICE_PERM_DENY 512 to the MDS server. 514 5. Security Considerations 516 All control operations from the MDS to the storage devices, including 517 any operations required for access permission checks in order to 518 detect permission denials to the MDS and the pNFS client, should be 519 authenticated in order to address cases when the access permission is 520 denied to the client by the administrator. It is expected that the 521 permission denial to a certain data server to a certain client will 522 be known to the MDS by configuration. This will be implemented for 523 all the pNFS layout types. 525 6. IANA Considerations 527 There are no IANA considerations in this document beyond pNFS IANA 528 Considerations are covered in [NFSV4.1]. 530 7. Conclusions 532 This draft specifies additions to the pNFS protocol addressing access 533 permission checks of the client and MDS server to storage devices 534 used in pNFS layouts for all layout types. 536 8. References 538 8.1. Normative References 540 [LEGAL] IETF Trust, "Legal Provisions Relating to IETF 541 Documents",URL http://trustee.ietf.org/docs/IETF-Trust- 542 License-Policy.pdf, November 2008. 544 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 545 Requirement Levels", BCP 14, RFC 2119, March 1997. 547 [NFSV4.1] Shepler, S., Eisler, M., and Noveck, D. ed., "NFSv4 Minor 548 Version 1", RFC [[RFC Editor: please insert NFSv4 Minor 549 Version 1 RFC number]], [[RFC Editor: please insert NFSv4 550 Minor Version 1 RFC month]] [[RFC Editor: please insert 551 NFSv4 Minor Version 1 year]. 552 . 555 [draft-ietf-nfsv4-pnfs-block-12] 556 Black, D., Glasgow, J., Fridella, S., "pNFS Block/Volume 557 Layout". 559 [XDR] Eisler, M., "XDR: External Data Representation Standard", 560 STD 67, RFC 4506, May 2006. 562 8.2. Informative References 564 [MPFS] EMC Corporation, "EMC Celerra Multi-Path File System", EMC 565 Data Sheet, available at: 566 http://www.emc.com/collateral/software/data-sheet/h2006- 567 celerra-mpfs-mpfsi.pdf 568 link checked 16 October 2009 570 9. Acknowledgments 572 This draft includes ideas from discussions with the authors of the 573 different pNFS layouts Jason Glasgow and Benny Halevy as well as pNFS 574 maintainer of Linux kernel including Bruce Fields. 576 This document was prepared using 2-Word-v2.0.template.dot. 578 Authors' Addresses 580 Sorin Faibish (editor) 581 EMC Corporation 582 32 Coslin Drive 583 Southboro, MA 01772 584 US 586 Phone: +1 (508) 305-8545 587 Email: sfaibish@emc.com 589 David L. Black 590 EMC Corporation 591 176 South Street 592 Hopkinton, MA 01748 593 US 595 Phone: +1 (508) 293-7953 596 Email: black_david@emc.com 598 Michael Eisler 599 NetApp 600 5765 Chase Point Circle 601 Colorado Springs, CO 80919 602 US 604 Phone: +1 (719) 599 8759 605 Email: mike@eisler.com