--- 1/draft-ietf-nfsv4-rfc3530bis-31.txt 2014-03-04 12:14:37.862464362 -0800 +++ 2/draft-ietf-nfsv4-rfc3530bis-32.txt 2014-03-04 12:14:38.406477572 -0800 @@ -1,19 +1,19 @@ NFSv4 T. Haynes, Ed. Internet-Draft NetApp Obsoletes: 3530 (if approved) D. Noveck, Ed. -Intended status: Standards Track February 13, 2014 -Expires: August 17, 2014 +Intended status: Standards Track March 04, 2014 +Expires: September 5, 2014 Network File System (NFS) Version 4 Protocol - draft-ietf-nfsv4-rfc3530bis-31.txt + draft-ietf-nfsv4-rfc3530bis-32.txt Abstract The Network File System (NFS) version 4 is a distributed file system protocol which builds on the heritage of NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. @@ -38,21 +38,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 17, 2014. + This Internet-Draft will expire on September 5, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -99,30 +99,30 @@ 3.2. Security Flavors . . . . . . . . . . . . . . . . . . . . 26 3.2.1. Security mechanisms for NFSv4 . . . . . . . . . . . 26 3.3. Security Negotiation . . . . . . . . . . . . . . . . . . 27 3.3.1. SECINFO . . . . . . . . . . . . . . . . . . . . . . 28 3.3.2. Security Error . . . . . . . . . . . . . . . . . . . 28 3.3.3. Callback RPC Authentication . . . . . . . . . . . . 28 4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 29 4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 30 4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 30 - 4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 31 + 4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 30 4.2.1. General Properties of a Filehandle . . . . . . . . . 31 - 4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 32 + 4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 31 4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 32 4.2.4. One Method of Constructing a Volatile Filehandle . . 33 4.3. Client Recovery from Filehandle Expiration . . . . . . . 34 - 5. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 35 + 5. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . 36 5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 36 - 5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 37 + 5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 36 5.4. Classification of Attributes . . . . . . . . . . . . . . 38 5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 39 5.6. REQUIRED Attributes - List and Definition References . . 39 5.7. RECOMMENDED Attributes - List and Definition References . . . . . . . . . . . . . . . . . . . . . . . 40 5.8. Attribute Definitions . . . . . . . . . . . . . . . . . 41 5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 41 5.8.2. Definitions of Uncategorized RECOMMENDED Attributes . . . . . . . . . . . . . . . . . . . . . 43 5.9. Interpreting owner and owner_group . . . . . . . . . . . 49 @@ -499,61 +499,65 @@ directory or file and referred to by a string name. Named attributes are meant to be used by client applications as a method to associate application-specific data with a regular file or directory. NFSv4.1 modifies named attributes relative to NFSv4.0 by tightening the allowed operations in order to prevent the development of non- interoperable implementations. Named attributes are discussed in Section 5.3. 1.3.3.3. Multi-server Namespace - NFSv4 contains a number of features to allow implementation of - namespaces that cross server boundaries and that allow and facilitate - a non-disruptive transfer of support for individual file systems - between servers. They are all based upon attributes that allow one - file system to specify alternate or new locations for that file - system. + A single-server namespace is the file system hierarchy that the + server presents for remote access. It is a proper subset of all the + file systems available locally. NFSv4 contains a number of features + to allow implementation of namespaces that cross server boundaries + and that allow and facilitate a non-disruptive transfer of support + for individual file systems between servers. They are all based upon + attributes that allow one file system to specify alternative or new + locations for that file system. I.e., just as a client might + traverse across local file systems on a single server, it can now + traverse to a remote file system on a different server. These attributes may be used together with the concept of absent file systems, which provide specifications for additional locations but no actual file system content. This allows a number of important facilities: o Location attributes may be used with absent file systems to implement referrals whereby one server may direct the client to a file system provided by another server. This allows extensive multi-server namespaces to be constructed. o Location attributes may be provided for present file systems to - provide the locations of alternate file system instances or + provide the locations of alternative file system instances or replicas to be used in the event that the current file system instance becomes unavailable. o Location attributes may be provided when a previously present file system becomes absent. This allows non-disruptive migration of - file systems to alternate servers. + file systems to alternative servers. 1.3.4. OPEN and CLOSE The NFSv4 protocol introduces OPEN and CLOSE operations. The OPEN operation provides a single point where file lookup, creation, and share semantics can be combined. The CLOSE operation also provides for the release of state accumulated by OPEN. 1.3.5. File Locking With the NFSv4 protocol, the support for byte range file locking is part of the NFS protocol. The file locking support is structured so that an RPC callback mechanism is not required. This is a departure from the previous versions of the NFS file locking protocol, Network - Lock Manager (NLM). The state associated with file locks is - maintained at the server under a lease-based model. The server + Lock Manager (NLM) [RFC1813]. The state associated with file locks + is maintained at the server under a lease-based model. The server defines a single lease period for all state held by a NFS client. If the client does not renew its lease within the defined period, all state associated with the client's lease may be released by the server. The client may renew its lease with use of the RENEW operation or implicitly by use of other operations (primarily READ). 1.3.6. Client Caching and Delegation The file, attribute, and directory caching for the NFSv4 protocol is similar to previous versions. Attributes and directory information @@ -1053,38 +1057,31 @@ Historically, NFSv2 and NFSv3 servers have resided on port 2049. The registered port 2049 [RFC3232] for the NFS protocol SHOULD be the default configuration. Using the registered port for NFS services means the NFS client will not need to use the RPC binding protocols as described in [RFC1833]; this will allow NFS to transit firewalls. Where an NFSv4 implementation supports operation over the IP network protocol, the supported transport layer between NFS and IP MUST be an IETF standardised transport protocol that is specified to avoid - network congestion; such transports include TCP and SCTP. To enhance - the possibilities for interoperability, an NFSv4 implementation MUST - support operation over the TCP transport protocol, at least until - such time as a standards track RFC revises this requirement to use a - different IETF standardised transport protocol with appropriate - congestion control. + network congestion; such transports include TCP and Stream Control + Transmission Protocol (SCTP). To enhance the possibilities for + interoperability, an NFSv4 implementation MUST support operation over + the TCP transport protocol. If TCP is used as the transport, the client and server SHOULD use persistent connections. This will prevent the weakening of TCP's congestion control via short lived connections and will improve performance for the Wide Area Network (WAN) environment by eliminating the need for SYN handshakes. - To date, all NFSv4 implementations are TCP based, i.e., there are - none for SCTP nor UDP. UDP by itself is not sufficient as a - transport for NFSv4, neither is UDP in combination with some other - mechanism (e.g., DCCP [RFC4340], NORM [RFC5740]). - As noted in Section 17, the authentication model for NFSv4 has moved from machine-based to principal-based. However, this modification of the authentication model does not imply a technical requirement to move the TCP connection management model from whole machine-based to one based on a per user model. In particular, NFS over TCP client implementations have traditionally multiplexed traffic for multiple users over a common TCP connection between an NFS client and server. This has been true, regardless of whether the NFS client is using AUTH_SYS, AUTH_DH, RPCSEC_GSS or any other flavor. Similarly, NFS over TCP server implementations have assumed such a model and thus @@ -1128,22 +1125,22 @@ 3.2. Security Flavors Traditional RPC implementations have included AUTH_NONE, AUTH_SYS, AUTH_DH, and AUTH_KRB4 as security flavors. With [RFC2203] an additional security flavor of RPCSEC_GSS has been introduced which uses the functionality of GSS-API [RFC2743]. This allows for the use of various security mechanisms by the RPC layer without the additional implementation overhead of adding RPC security flavors. For NFSv4, the RPCSEC_GSS security flavor MUST be used to enable the - mandatory security mechanism. Other flavors, such as, AUTH_NONE, - AUTH_SYS, and AUTH_DH MAY be implemented as well. + mandatory to implement security mechanism. Other flavors, such as, + AUTH_NONE, AUTH_SYS, and AUTH_DH MAY be implemented as well. 3.2.1. Security mechanisms for NFSv4 RPCSEC_GSS, via GSS-API, supports multiple mechanisms that provide security services. For interoperability, NFSv4 clients and servers MUST support the Kerberos V5 security mechanism. The use of RPCSEC_GSS requires selection of mechanism, quality of protection (QOP), and service (authentication, integrity, privacy). For the mandated security mechanisms, NFSv4 specifies that a QOP of @@ -1202,23 +1199,23 @@ or server, so there is some due diligence required by the user of NFSv4 to ensure that security is acceptable where needed. Guidance is provided in [RFC6649] as to why weak algorithms should be disabled by default. 3.3. Security Negotiation With the NFSv4 server potentially offering multiple security mechanisms, the client needs a method to determine or negotiate which mechanism is to be used for its communication with the server. The - NFS server may have multiple points within its file system name space + NFS server can have multiple points within its file system name space that are available for use by NFS clients. In turn the NFS server - may be configured such that each of these entry points may have + can be configured such that each of these entry points can have different or multiple security mechanisms in use. The security negotiation between client and server SHOULD be done with a secure channel to eliminate the possibility of a third party intercepting the negotiation sequence and forcing the client and server to choose a lower level of security than required or desired. See Section 17 for further discussion. 3.3.1. SECINFO @@ -1230,21 +1227,21 @@ It is possible that the server's policies change during the client's interaction therefore forcing the client to negotiate a new security triple. 3.3.2. Security Error Based on the assumption that each NFSv4 client and server MUST support a minimum set of security (i.e., Kerberos-V5 under RPCSEC_GSS), the NFS client will start its communication with the server with one of the minimal security triples. During - communication with the server, the client may receive an NFS error of + communication with the server, the client can receive an NFS error of NFS4ERR_WRONGSEC. This error allows the server to notify the client that the security triple currently being used is not appropriate for access to the server's file system resources. The client is then responsible for determining what security triples are available at the server and choose one which is appropriate for the client. See Section 15.33 for further discussion of how the client will respond to the NFS4ERR_WRONGSEC error and use SECINFO. 3.3.3. Callback RPC Authentication @@ -1345,25 +1342,26 @@ and the ROOT filehandle refer to the same file system object. However, it is up to the administrative software at the server and the policies of the server administrator to define the binding of the PUBLIC filehandle and server file system object. The client may not make any assumptions about this binding. The client uses the PUBLIC filehandle via the PUTPUBFH operation. 4.2. Filehandle Types In the NFSv2 and NFSv3 protocols, there was one type of filehandle - with a single set of semantics. This type of filehandle is termed - "persistent" in NFS Version 4. The semantics of a persistent - filehandle remain the same as before. A new type of filehandle - introduced in NFS Version 4 is the "volatile" filehandle, which - attempts to accommodate certain server environments. + with a single set of semantics, of which the primary one was that it + was peristent across a server reboot. As such, this type of + filehandle is termed "persistent" in NFS Version 4. The semantics of + a persistent filehandle remain the same as before. A new type of + filehandle introduced in NFS Version 4 is the "volatile" filehandle, + which attempts to accommodate certain server environments. The volatile filehandle type was introduced to address server functionality or implementation issues which make correct implementation of a persistent filehandle infeasible. Some server environments do not provide a file system level invariant that can be used to construct a persistent filehandle. The underlying server file system may not provide the invariant or the server's file system programming interfaces may not provide access to the needed invariant. Volatile filehandles may ease the implementation of server functionality such as hierarchical storage management or file @@ -1606,31 +1604,31 @@ not the underlying file system at the server has a named attribute directory. Therefore, operations such as SETATTR and GETATTR on the named attribute directory are undefined. 5.1. REQUIRED Attributes These MUST be supported by every NFSv4.0 client and server in order to ensure a minimum level of interoperability. The server MUST store and return these attributes, and the client MUST be able to function with an attribute set limited to these attributes. With just the - REQUIRED attributes some client functionality may be impaired or - limited in some ways. A client may ask for any of these attributes + REQUIRED attributes some client functionality can be impaired or + limited in some ways. A client can ask for any of these attributes to be returned by setting a bit in the GETATTR request, and the server MUST return their value. 5.2. RECOMMENDED Attributes These attributes are understood well enough to warrant support in the NFSv4.0 protocol. However, they may not be supported on all clients and servers. A client MAY ask for any of these attributes to be - returned by setting a bit in the GETATTR request but must handle the + returned by setting a bit in the GETATTR request but MUST handle the case where the server does not return them. A client MAY ask for the set of attributes the server supports and SHOULD NOT request attributes the server does not support. A server should be tolerant of requests for unsupported attributes and simply not return them rather than considering the request an error. It is expected that servers will support all attributes they comfortably can and only fail to support attributes that are difficult to support in their operating environments. A server should provide attributes whenever they don't have to "tell lies" to the client. For example, a file modification time should be either an accurate time or should not be @@ -3608,21 +3606,21 @@ accessible via normal namespace operations (e.g., LOOKUP). In this case, the file system is said to be "present" at that position in the namespace, and clients will typically use it, reserving use of additional locations specified via the location-related attributes to situations in which the principal location is no longer available. When there is no actual file system at the namespace location in question, the file system is said to be "absent". An absent file system contains no files or directories other than the root. Any reference to it, except to access a small set of attributes useful in - determining alternate locations, will result in an error, + determining alternative locations, will result in an error, NFS4ERR_MOVED. Note that if the server ever returns the error NFS4ERR_MOVED, it MUST support the fs_locations attribute. While the error name suggests that we have a case of a file system that once was present, and has only become absent later, this is only one possibility. A position in the namespace may be permanently absent with the set of file system(s) designated by the location attributes being the only realization. The name NFS4ERR_MOVED reflects an earlier, more limited conception of its function, but this error will be returned whenever the referenced file system is @@ -3742,28 +3740,28 @@ facilities in providing reliable, manageable, and scalable data access. When a file system is present, these attributes can provide alternative locations, to be used to access the same data, in the event of server failures, communications problems, or other difficulties that make continued access to the current file system impossible or otherwise impractical. Under some circumstances, multiple alternative locations may be used simultaneously to provide higher-performance access to the file system in question. Provision - of such alternate locations is referred to as "replication" although - there are cases in which replicated sets of data are not in fact - present, and the replicas are instead different paths to the same - data. + of such alternative locations is referred to as "replication" + although there are cases in which replicated sets of data are not in + fact present, and the replicas are instead different paths to the + same data. When a file system is present and becomes absent, clients can be given the opportunity to have continued access to their data, at an - alternate location. In this case, a continued attempt to use the + alternative location. In this case, a continued attempt to use the data in the now-absent file system will result in an NFS4ERR_MOVED error and, at that point, the successor locations (typically only one although multiple choices are possible) can be fetched and used to continue access. Transfer of the file system contents to the new location is referred to as "migration", but it should be kept in mind that there are cases in which this term can be used, like "replication", when there is no actual data migration per se. Where a file system was not previously present, specification of file system location provides a means by which file systems located on one @@ -3774,74 +3772,74 @@ Because client support for location-related attributes is OPTIONAL, a server may (but is not required to) take action to hide migration and referral events from such clients, by acting as a proxy, for example. 8.4.1. File System Replication The fs_locations attribute provides alternative locations, to be used to access data in place of or in addition to the current file system instance. On first access to a file system, the client should obtain - the value of the set of alternate locations by interrogating the + the value of the set of alternative locations by interrogating the fs_locations attribute. In the event that server failures, communications problems, or other difficulties make continued access to the current file system - impossible or otherwise impractical, the client can use the alternate - locations as a way to get continued access to its data. Multiple - locations may be used simultaneously, to provide higher performance - through the exploitation of multiple paths between client and target - file system. + impossible or otherwise impractical, the client can use the + alternative locations as a way to get continued access to its data. + Multiple locations may be used simultaneously, to provide higher + performance through the exploitation of multiple paths between client + and target file system. - The alternate locations may be physical replicas of the (typically - read-only) file system data, or they may reflect alternate paths to + The alternative locations may be physical replicas of the (typically + read-only) file system data, or they may reflect alternative paths to the same server or provide for the use of various forms of server - clustering in which multiple servers provide alternate ways of + clustering in which multiple servers provide alternative ways of accessing the same physical file system. How these different modes of file system transition are represented within the fs_locations attribute and how the client deals with file system transition issues will be discussed in detail below. Multiple server addresses, whether they are derived from a single entry with a DNS name representing a set of IP addresses or from multiple entries each with its own server address, may correspond to the same actual server. 8.4.2. File System Migration When a file system is present and becomes absent, clients can be given the opportunity to have continued access to their data, at an - alternate location, as specified by the fs_locations attribute. + alternative location, as specified by the fs_locations attribute. Typically, a client will be accessing the file system in question, get an NFS4ERR_MOVED error, and then use the fs_locations attribute to determine the new location of the data. Such migration can be helpful in providing load balancing or general resource reallocation. The protocol does not specify how the file system will be moved between servers. It is anticipated that a number of different server-to-server transfer mechanisms might be used with the choice left to the server implementor. The NFSv4 protocol specifies the method used to communicate the migration event between client and server. - The new location may be an alternate communication path to the same + The new location may be an alternative communication path to the same server or, in the case of various forms of server clustering, another server providing access to the same physical file system. The client's responsibilities in dealing with this transition depend on the specific nature of the new access path as well as how and whether data was in fact migrated. These issues will be discussed in detail below. - When an alternate location is designated as the target for migration, - it must designate the same data. Where file systems are writable, a - change made on the original file system must be visible on all - migration targets. Where a file system is not writable but + When an alternative location is designated as the target for + migration, it must designate the same data. Where file systems are + writable, a change made on the original file system must be visible + on all migration targets. Where a file system is not writable but represents a read-only copy (possibly periodically updated) of a writable file system, similar requirements apply to the propagation of updates. Any change visible in the original file system must already be effected on all migration targets, to avoid any possibility that a client, in effecting a transition to the migration target, will see any reversion in file system state. 8.4.3. Referrals Referrals provide a way of placing a file system in a location within @@ -3885,21 +3883,21 @@ As mentioned above, a single location entry may have a server address target in the form of a DNS name that may represent multiple IP addresses, while multiple location entries may have their own server address targets that reference the same server. When multiple addresses for the same server exist, the client may assume that for each file system in the namespace of a given server network address, there exist file systems at corresponding namespace locations for each of the other server network addresses. It may do this even in the absence of explicit listing in fs_locations. Such - corresponding file system locations can be used as alternate + corresponding file system locations can be used as alternative locations, just as those explicitly specified via the fs_locations attribute. If a single location entry designates multiple server IP addresses, the client cannot assume that these addresses are multiple paths to the same server. In most cases, they will be, but the client MUST verify that before acting on that assumption. When two server addresses are designated by a single location entry and they correspond to different servers, this normally indicates some sort of misconfiguration, and so the client should avoid using such location @@ -3953,21 +3951,21 @@ NFS4ERR_BAD_STATEID when the client uses those stateids on the new server. The server MUST return NFS4ERR_STALE_STATEID when the client uses those stateids on the old server, regardless of whether migration has occurred or not. 8.7. Effecting File System Referrals Referrals are effected when an absent file system is encountered, and - one or more alternate locations are made available by the + one or more alternative locations are made available by the fs_locations attribute. The client will typically get an NFS4ERR_MOVED error, fetch the appropriate location information, and proceed to access the file system on a different server, even though it retains its logical position within the original namespace. Referrals differ from migration events in that they happen only when the client has not previously referenced the file system in question (so there is nothing to transition). Referrals can only come into effect when an absent file system is encountered at its root. The examples given in the sections below are somewhat artificial in @@ -4306,21 +4304,21 @@ the current server's namespace, i.e., that of the server from which the fs_locations attribute was obtained. The fs_root path is meant to aid the client by clearly referencing the root of the file system whose locations are being reported, no matter what object within the current file system the current filehandle designates. The fs_root is simply the pathname the client used to reach the object on the current server (i.e., the object to which the fs_locations attribute applies). When the fs_locations attribute is interrogated and there are no - alternate file system locations, the server SHOULD return a zero- + alternative file system locations, the server SHOULD return a zero- length array of fs_location4 structures, together with a valid fs_root. As an example, suppose there is a replicated file system located at two servers (servA and servB). At servA, the file system is located at path /a/b/c. At, servB the file system is located at path /x/y/z. If the client were to obtain the fs_locations value for the directory at /a/b/c/d, it might not necessarily know that the file system's root is located in servA's namespace at /a/b/c. When the client switches to servB, it will need to determine that the directory it @@ -6144,27 +6142,28 @@ network distance of the clients that will be accessing the server's resources. It is expected that the lease period will take into account the network propagation delays and other network delay factors for the client population. Since the protocol does not allow for an automatic method to determine an appropriate lease period, the server's administrator may have to tune the lease period. 9.14. Migration, Replication and State When responsibility for handling a given file system is transferred - to a new server (migration) or the client chooses to use an alternate - server (e.g., in response to server unresponsiveness) in the context - of file system replication, the appropriate handling of state shared - between the client and server (i.e., locks, leases, stateids, and - client IDs) is as described below. The handling differs between - migration and replication. For related discussion of file server - state and recover of such see the sections under Section 9.6. + to a new server (migration) or the client chooses to use an + alternative server (e.g., in response to server unresponsiveness) in + the context of file system replication, the appropriate handling of + state shared between the client and server (i.e., locks, leases, + stateids, and client IDs) is as described below. The handling + differs between migration and replication. For related discussion of + file server state and recover of such see the sections under + Section 9.6. If a server replica or a server immigrating a file system agrees to, or is expected to, accept opaque values from the client that originated from another server, then servers SHOULD encode the "opaque" values in network byte order. This way, servers acting as replicas or immigrating file systems will be able to parse values like stateids, directory cookies, filehandles, etc. even if their native byte order is different from other servers cooperating in the replication and migration of the file system. @@ -13667,45 +13666,37 @@ [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005. [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism", RFC 4178, October 2005. - [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram - Congestion Control Protocol (DCCP)", RFC 4340, March 2006. - [RFC4506] Eisler, M., "XDR: External Data Representation Standard", RFC 4506, May 2006. [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, January 2010. - [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, - "Negative-acknowledgment (NACK)-Oriented Reliable - Multicast (NORM) Transport Protocol", RFC 5740, - November 2009. - [fcntl] The Open Group, "Section 'fcntl()' of System Interfaces of The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition, HTML Version (www.opengroup.org), ISBN 1931624232", 2004. [fsync] The Open Group, "Section 'fsync()' of System Interfaces of The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition, HTML Version (www.opengroup.org), ISBN 1931624232", 2004.