idnits 2.17.1 draft-andros-nfsv4-client-multipath-discovery-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 (February 9, 2017) is 2632 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 5661 (Obsoleted by RFC 8881) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network File System Version 4 W. Adamson 3 Internet-Draft NetApp 4 Intended status: Standards Track C. Lever, Ed. 5 Expires: August 13, 2017 Oracle 6 February 9, 2017 8 Trunking Discovery For Network File System Version 4.1 9 draft-andros-nfsv4-client-multipath-discovery-00 11 Abstract 13 Connection trunking is the use of multiple transport connections to 14 increase data and request throughput between one NFS client and 15 server pair. This document describes a means for an NFS version 4.1 16 client to discover NFS version 4.1 server multipath addresses that 17 may be used for connection trunking. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in [RFC2119]. 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 August 13, 2017. 42 Copyright Notice 44 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Discovering Multipath Addresses . . . . . . . . . . . . . . . 4 62 4. Trunking Support For Other NFS Versions . . . . . . . . . . . 11 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 65 7. Normative References . . . . . . . . . . . . . . . . . . . . 12 66 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 69 1. Introduction 71 Multiple transport connections can be established between an NFS 72 client and server pair to improve the throughput of RPC operations or 73 data transfer. These connections leverage the bandwidth of multiple 74 network paths, potentially making use of more than one network 75 interface or execution engine on both the client and server. 77 NFS version 4.1 defines two mechanisms for managing multiple 78 transport connections between a single client-server pair. 79 Section 2.10.5 of [RFC5661] defines "trunking" as the use of multiple 80 transport connections to increase the speed of data transfer. 81 Chapters 12 and 13 of that document introduce Parallel NFS (pNFS), 82 wherein multiple transport connections may be established to pNFS 83 Data Servers (DSs). This document refers to these multiple DS 84 connections as "multipathing". 86 The NFSv4.1 GETDEVICEINFO operation enables multipathing among 87 multiple pNFS Data Server (DS) network addresses. As noted in 88 Section 13.5 of [RFC5661], if multiple network addresses appear in a 89 multipath list, they designate the same Data Server. Given a such a 90 list of multipath addresses, a client tests further for trunking 91 support by sending an EXCHANGE_ID operation to each address in a 92 multipath list and comparing the results. 94 The NFS version 4.1 protocol does not specify a similar means for an 95 NFS version 4.1 client to discover multipath addresses to enable 96 trunking for a pNFS Meta Data Server (MDS), nor for an NFS version 97 4.1 server where pNFS is not in use. 99 This document describes a mechanism for an NFS version 4.1 server to 100 advertise multipath addresses that may be used for "connection 101 trunking": establishing multiple transport connections outside the 102 auspices of pNFS. This document does not discuss how an NFS client 103 utilizes connection trunking to achieve better performance. 105 1.1. Clientid And Session Trunking 107 The initial interaction between an NFSv4.1 client and server is an 108 exchange of the unique identities of both peers. During that 109 exchange, the server presents the client with a token which the 110 client uses as a shorthand for its identity during subsequent 111 interactions with the server. This token is known as a client ID, 112 which is returned to the client as a result in the NFSv4.1 113 EXCHANGE_ID operation. 115 The NFS version 4.1 protocol introduces the concept of a session. A 116 session enables a server to manage state associated with each client 117 independent of that client's transport connections, which are 118 transient. Section 2.10.1 of [RFC5661] provides a detailed overview 119 of sessions. 121 Each NFSv4.1 client is typically associated with one client ID. A 122 client is allowed to instantiate multiple sessions, which are all 123 associated with its client ID. This is referred to as client ID 124 trunking. 126 An NFS version 4.1 client associates an otherwise unbound transport 127 connection to an existing session by sending a BIND_CONN_TO_SESSION 128 operation on that connection. It might do this if, for instance, a 129 network partition caused the original transport connection associated 130 with a session to be lost. Using BIND_CONN_TO_SESSION operations, 131 more than one transport connection can be associated with, or trunked 132 to, the same session. This is referred to as session trunking. 134 An NFS client can employ either client ID trunking or session 135 trunking to trunk connections to a pNFS Meta Data Server or non-pNFS 136 server. 138 2. Terminology 140 Client ID trunking 141 The association of multiple sessions to the same client ID. 143 Connection trunking 144 The use of multiple transport connections between a single NFS 145 client and server pair, outside the context of pNFS. Includes 146 client ID and session trunking. 148 fs_locations and fs_locations_info 149 File system attributes, retrieved via a GETATTR operation, that 150 describe NFS server locations where a file system may be found. 152 Multipath address 153 A network address of an NFS version 4.1 server that may be used 154 for connection trunking. 156 Multipathing 157 The use of multiple transport connections between a single NFS 158 client and server pair, in the context of a pNFS layout. 160 pNFS Data Server 161 A storage service that stores only file data. 163 pNFS Meta Data Server 164 A storage service that manages pNFS layouts, which direct clients 165 to pNFS Data Servers. 167 Pseudo file system 168 A read-only file system that bridges the non-accessible portions 169 of a server's externally accessible file system namespace. 171 Replicas 172 Alternative locations to be used to access data in place of, or in 173 addition to, the current file system instance. 175 Session trunking 176 The association of multiple transport connections to the same 177 session. 179 3. Discovering Multipath Addresses 181 3.1. Querying Locations 183 The fs_locations attribute (Section 11.9 [RFC5661]), and the 184 fs_locations_info attribute (Section 11.10 [RFC5661]) provide a list 185 of replica servers for an externally accessible file system. 186 Section 11.4 of [RFC5661] defines replication as follows: 188 Under some circumstances, multiple alternative locations may be 189 used simultaneously to provide higher-performance access to the 190 file system in question. Provision of such alternate locations is 191 referred to as "replication" although there are cases in which 192 replicated sets of data are not in fact present, and the replicas 193 are instead different paths to the same data. 195 3.2. Pseudo File Systems 197 Section 7.3 of [RFC5661] describes the "pseudo file system" as a 198 framework to present all exports for an NFS version 4.1 server in a 199 single local namespace. The pseudo file system bridges the 200 unexported portions of a server's local file system namespace 201 providing a view of only externally accessible exported directories. 203 Because a pseudo file system holds a dynamically-constructed read- 204 only local traversal path to all externally accessible file systems 205 specific to that server, it is not normally a candidate for any 206 fs_locations nor fs_locations_info query. This includes queries for 207 replication or migration information, as a server's pseudo file 208 system is never replicated or migrated because it is unique to that 209 server. 211 3.3. Obtaining Multipath Information For Connection Trunking 213 Multipath addresses suitable for connection trunking are a server- 214 wide resource, as they provide a means to reach all exported file 215 systems on a server. The pseudo file system is a server-wide file 216 system in the sense that it provides a traversal path to all exported 217 file systems on a server. 219 Thus we define an fs_locations and fs_locations_info replica list on 220 the pseudo file system as a list of multipath addresses for the 221 server to be tested for connection trunking. 223 This scheme relies on a new restriction on the pseudo file system. 224 The NFSv4.1 server exported pseudo file system root "/", as seen by 225 clients, MUST NOT be migrated or replicated in a way that NFS clients 226 can be aware of. 228 To guarantee a client is getting the location information from a 229 server's pseudo file system, and not from a real file system on that 230 server, the client MUST probe the root directory of the pseudo file 231 system using GETATTR with the fs_locations or fs_locations_info 232 attribute. 234 Clients can make good use of information about what transport type to 235 use (eg. RDMA or TCP) for each multipath address, and some idea of 236 the relative performance of each multipath address (eg. 10GbE, 40GbE, 237 FDR RDMA, and so on). This class of information can be encoded in an 238 fs_locations_info attribute, but is not conveyed in fs_locations. 240 The text in Section 11.10 of [RFC5661] suggests that the fs_locations 241 attribute may be deprecated in favor of fs_locations_info. 243 Therefore, this document RECOMMENDs the use of fs_locations_info over 244 fs_locations to convey the list of multipath addresses. 246 3.3.1. Constructing The Multipath List 248 A multi-homed server knows neither the connectivity nor the 249 performance characteristics of the network path between a client and 250 each of it's network interfaces. As such, the server SHOULD 251 enumerate all of it's network interfaces in constructing the 252 connection trunking multipath address list for the pseudo file 253 system. This allows each client to test each multipath address and 254 make a connectivity and performance determination. 256 Mixing slow and fast transports in connection trunking can be 257 problematic if the client algorithm for choosing which trunked 258 transport to use does not take transport characteristics into 259 account. Indeed, Section 13.5 [RFC5661] notes that for DS multipath 260 address the MDS SHOULD NOT mix slow and fast transports. For 261 connection trunking multipath address list construction, the server 262 should take the transport speed into consideration. An 263 fs_locations_info multipath list can use fls_info flags 264 (Section 3.3.1.2) to communicate transport characteristics. An 265 fs_locations multipath list depends on the following ordering of 266 interfaces to convey some notion of transport characteristics: 268 o Place TCP transports first, followed by RDMA transports. 270 o Order the transports by performance, with highest performance 271 transports first. E.g. for TCP, 40GbE, 10GbE, then 1GbE. 273 o For each transport with equal performance, group by address 274 family. E.G. for TCP 10GbE, group IPv4 addresses, then IPv6 275 addresses. 277 3.3.1.1. Constructing An fs_locations Multipath List 279 When creating an fs_locations pseudofs multipath replica list, the 280 server fs_locations4 locations list SHOULD be ordered as described 281 above in Section 3.3.1. 283 An entry in the fs_location4 server array is formed as defined in 284 Section 11.9 [RFC5661]. 286 The fs_locations4 fs_root and each fs_location4 rootpath MUST be set 287 to "/" to indicate this fs_locations replica list is on the pseudo 288 file system. 290 3.3.1.2. Use of fs_locations_info FSLI4BX Flags With Connection 291 Trunking 293 As noted in Section 3.1 both the fs_locations and fs_locations_info 294 attributes are designed to describe alternative locations for 295 exported file systems. The pseudo file system replica list describes 296 a server-wide resource, so file system specific information encoded 297 in the fs_locations_info attribute has no meaning. 299 When creating an fs_locations_info pseudofs multipath replica list, 300 the server SHOULD NOT set the FSLI4BX_GFLAGS, FSLI4BX_CLSIMUL, 301 FSLI4BX_CLHANDLE, FSLI4BX_CLFILEID, FSLI4BX_CLWRITEVER, 302 FSLI4BX_CLCHANGE, nor FSLI4BX_CLREADDIR fs_locations_server4 fls_info 303 flag fields. The client MUST ignore these flags. 305 File system specific information such as the meaning of the FSLI4BX 306 RANK and ORDER values and read-only versus writeable file systems 307 have no meaning for the connection trunking fs_locations_info 308 multipath list. There is information beyond the multipath address 309 that is useful to the client that can be expressed in the RANK and 310 ORDER values. We arbitrarily choose to use the FSLI4BX_READRANK and 311 FSLI4BX_READORDER values and redefine the meaning of FSLI4BX_READRANK 312 and FSLI4BX_READORDER when used for connection trunking below. 314 The server SHOULD NOT set either the field at byte index 315 FSLI4BX_WRITERANK nor FSLI4BX_WRITEORDER. The client MUST ignore 316 these byte fields when interpreting the fs_locations_info multipath 317 list. 319 Section 11.10.1 [RFC5661] describes the use of the server imposed 320 rank and order file system values which overrides client preferences. 321 The client connectivity characteristics of a multipath address are 322 typically not visible to the server, so connection trunking mulipath 323 lists do not interpret the FSLI4BX_READRANK or FSLI4BX_READORDER 324 values as overriding client preferences, but rather as additional 325 information that the client can use to setup connection trunking. 326 The server SHOULD set the FSLI4BX_READRANK and FSLI4BX_READORDER 327 fs_locations_server4 fls_info flag fields for each entry as follows. 329 The FSLI4BX_READRANK value is redefined as the server "interface 330 index" with a unique value for each server interface. Two connection 331 trunking fs_locations_server4 fls_info FSLI4BX_READRANK values that 332 are the same indicates that the fs_locations_server4 entries refer to 333 the same server interface. This can occur, for example, if a server 334 interface has multiple IPv4 addresses, or an IPv4 and an IPv6 address 335 assigned and entered in the connection trunking multipath list. 337 The FSLI4BX_READORDER value is redefined as the "relative interface 338 performance". For connection trunking, the FSLI4BX_READORDER is no 339 longer used for ordering within the FSLI4BX_READRANK value but 340 instead orders the fs_locations_server4 fli_entries list. 341 FSLI4BX_READORDER is a value that orders the server interface's 342 relative performance with the higher performing interfaces having a 343 larger FSLI4BX_READORDER value. This value MAY equal the transmit 344 size of the Network Interface Card (NIC) e.g. a value of 40 for a 40G 345 NIC. 347 3.3.1.3. Constructing An fs_locations_info Multipath List 349 When creating an fs_locations_info connection trunking multipath 350 list, the server fs_locations_item4 fli_entries list SHOULD be 351 ordered as described above in Section 3.3.1 with the appropriate 352 FSLI4BX_READRANK and FSLI4BX_READORDER fls_info values. 354 There is no FSLI4BX_TFLAG for ethernet, so for ethernet 355 fs_locations_server4 entries the FSLI4BX_TFLAG is not set. The 356 server MUST set the FSLI4BX_TFLAGS fls_info byte value to 357 FSLI4TF_RDMA on an RDMA fs_locations_server4 entry. 359 The fs_locations_server4 fls_currency field has no meaning for a 360 multipath list, and so SHOULD be set to zero. The client MUST ignore 361 the fls_currency field. 363 The fs_locations_server4 fli_flags and flli_valid_for fields have no 364 meaning for a multipath list, and so SHOULD be set to zero. The 365 client MUST ignore the fli_flags and flli_valid_for fields. 367 The fs_locations_server4 fls_server is formed as described in 368 Section 11.10.1 of [RFC5661]. 370 The fs_locations_info connection trunking multipath list will consist 371 of a single fs_locations_info4 fli_items entry, as all entries share 372 a common rootpath, that of the pseudo file system. The 373 fs_locations_info4 fli_fs_root and the fs_locations_item4 374 fli_rootpath MUST be set to "/" to confirm this fs_locations_info 375 replica list is on the pseudo file system. 377 3.3.2. Querying for Multipath Information 379 Unlike the DS multipath list provided by GETDEVICEINFO, neither 380 fs_locations nor fs_locations_info attributes has a client cache 381 coherency feature. The client SHOULD query for multipath information 382 on mount and reboot. The client SHOULD refresh the connection 383 trunking multipath information whenever the connection goes away on 384 one or more addresses without a reboot. The client MAY query every 385 couple of hours or so to discover new multipath addresses. 387 The client MAY want to query every hour or so when a multipath list 388 is not present to detect a newly instantiated list. 390 Section 11.9 of [RFC5661] When a multipath-capable client sends an 391 fs_locations request to a (legacy) server that does not support the 392 multipath list, the server SHOULD return a zero-length array of 393 fs_location4 structures 395 A multipath-capable client can query a (legacy) server that supports 396 the fs_locations or fs_locations_info attribute but does not support 397 the connection trunking multipath list on the pseudo file system. In 398 this case, the server SHOULD behave as Section 11.9 of [RFC5661] 399 describes: the server SHOULD return an fs_locations4 data type with a 400 zero-length locations array and the fs_root set to "/" on an 401 fs_locations attribute query. For an fs_locations_info attribute 402 query, the server SHOULD return a zero length fli_items array of 403 fs_location_info4 structures with the fli_fs_root set to "/" and the 404 fli_flags and fli_valid_for both set to zero. 406 3.3.3. Resolving Server Identity 408 Section 2.10.5 [RFC5661] describes how a client uses EXCHANGE_ID to 409 resolve server identity ambiguity, and test for session and/or client 410 ID trunking. Connection trunking uses these methods. 412 3.3.4. Connection Trunking Example 414 Here we provide an example exchange between a client and a multi- 415 homed server. The example server has two 10G interfaces, a 1G 416 interface, and a 40G RDMA interface. All interfaces have both IPv4 417 and IPv6 addresses assigned to them. 419 Following the rules in Section 3.3.1, the server orders it's 420 interfaces and associated addresses to construct the connection 421 trunking multipath address list as follows: The first 10G(IPv4) 422 address, the second 10G(IPv4) address, the first 10G(IPv6) address, 423 the second 10G(IPv6) address, the 1G(IPv4) address, the 1G(IPv6) 424 address, the RDMA(IPv4) address, and finally, the RDMA(IPv6) address. 425 This example server interface ordering is used for both the 426 fs_locations and the fs_locations_info lists 428 The fs_locations list consists of an fs_locations4 structure with the 429 fs_root set to "/" and a locations list where each fs_location4 entry 430 has a rootpath value set to "/" and a server string representation of 431 the interface addresses in the above example server interface list 432 order. 434 The fs_locations_info list consists of an fs_locations_info4 struct 435 with the fli_flags and fli_valid_for fields set to zero, the 436 fli_fs_root root set to "/" and an fli_items list with one entry. 437 The single fli_items fs_locations_item4 struct has the fli_rootpath 438 set to "/" and an fs_locations_server4 struct for each item in the 439 above example server interface list order. Each fs_locations_server4 440 structure in the list has the fls_currency set to zero, the 441 fls_server is the same as the fs_locations server string, and the 442 fls_info array set as described in Section 3.3.1.2 and shown here: 444 o The first 10G interface IPv4 address: FSLI4BX_READRANK=1, 445 FSLI4BX_READORDER=10 447 o The second 10G interface IPv4 address: FSLI4BX_READRANK=2, 448 FSLI4BX_READORDER=10 450 o The first 10G interface IPv6 address: FSLI4BX_READRANK=1, 451 FSLI4BX_READORDER=10 453 o The second 10G interface IPv6 address: FSLI4BX_READRANK=2, 454 FSLI4BX_READORDER=10 456 o The 1G interface IPv4 address: FSLI4BX_READRANK=3, 457 FSLI4BX_READORDER=1 459 o The 1G interface IPv6 address: FSLI4BX_READRANK=3, 460 FSLI4BX_READORDER=1 462 o The RDMA interface IPv4 address: FSLI4BX_TFLAGS=FSLI4TF_RDMA, 463 FSLI4BX_READRANK=4, FSLI4BX_READORDER=40 465 o The RDMA interface IPv6 address: FSLI4BX_TFLAGS=FSLI4TF_RDMA, 466 FSLI4BX_READRANK=4, FSLI4BX_READORDER=40 468 Note that the fs_locations_info list provides more information than 469 the fs_locations list as the FSLI4BX_READRANK identifies the 470 interfaces, and the FSLI4BX_READORDER value is the network interface 471 card size. 473 The client queries the server as described in Section 3.3.2 and 474 parses the returned fs_locations or fs_locations_info multipath 475 address list. The client may decide to ping a multipath address with 476 a NULLPROC RPC to determine connectivity and round trip performance. 478 An EXCHANGE_ID is then sent to each address that the client wants to 479 test for connection trunking as described in Section 3.3.3. 481 4. Trunking Support For Other NFS Versions 483 NFS versions other than NFSv4.1 can also support trunking if they 484 provide the following protocol features: 486 o A place to pin the multipath list on the server. For NFSv4.1, 487 this is the pseudo file system fs_locations or fs_locations_info 488 multipath list as described in Section 3.3.1. 490 o A mechanism for the client to retrieve the multipath list. For 491 NFSv4.1, this is an fs_locations or fs_locations_info query as 492 described in Section 3.3.1. 494 o A client recipe for determining whether trunking is supported on a 495 multipath address. For NFSv4.1, this is the use of an EXCHANGE_ID 496 query as described in Section 3.3.3 . 498 For example, NFSv4.2 can directly use the NFSv4.1 trunking support 499 described in this document. 501 NFSv4.0 can provide client ID trunking by pinning the multipath list 502 on the server's pseudo file system and using an fs_locations query as 503 a retrieval mechanism as describe for NFSv4.1 in this document. 504 NFSv4.0 can then use SETCLIENTID and SETCLIENTID_CONFIRM calls as 505 described in Section 5.8 [RFC7931] to determine whether trunking is 506 supported on a multipath address. 508 5. Security Considerations 510 The traditional NFS security model controls access to shared file 511 systems based on a client's IP address. When multiple transport 512 connections are in play, a client request can appear from any one of 513 its network interfaces. Therefore, clients should rely on 514 authentication of individual users to ensure share access is 515 controlled appropriately. The client's IP address becomes ever less 516 meaningful as a mode of access control. 518 An injection of the IP address of a man-in-the-middle system is 519 easily done by replacing an IP address in a multipath list as a 520 GETATTR(fs_locations) reply is conveyed back to a client. 521 Recommendations to protect GETATTR(fs_locations) [RFC5661] and 522 SETCLIENTID [RFC7530] (and EXCHANGE_ID for NFSv4.1) with an 523 integrity-protecting security service are key to preventing such an 524 attack. 526 As an additional step, Section 2.10.5.1 of [RFC5661] recommends that 527 clients reliably verify a server's claims of trunking support for a 528 session or client ID using strong authentication of the server that 529 responds on each IP address in a multipath list. 531 6. IANA Considerations 533 There are no IANA considerations for this document. 535 7. Normative References 537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 539 RFC2119, March 1997, 540 . 542 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 543 "Network File System (NFS) Version 4 Minor Version 1 544 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, 545 . 547 [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 548 (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, 549 March 2015, . 551 [RFC7931] Noveck, D., Ed., Shivam, P., Ed., Lever, C., Ed., and B. 552 Baker, Ed., "NFSv4.0 Migration: Specification Update", RFC 553 7931, DOI 10.17487/RFC7931, July 2016, 554 . 556 Appendix A. Acknowledgments 558 Andy Adamson would like to thank NetApp, Inc. for its funding of his 559 time on this project. 561 Authors' Addresses 563 William A. (Andy) Adamson 564 NetApp 565 3629 Wagner Ridge Ct 566 Ann Arbor, MI 48103 567 USA 569 Email: andros@netapp.com 570 Charles Lever (editor) 571 Oracle Corporation 572 1015 Granger Avenue 573 Ann Arbor, MI 48104 574 USA 576 Phone: +1 248 816 6463 577 Email: chuck.lever@oracle.com