draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34: Task Force (IETF). Note that other groups may also distribute draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:39: and may be updated, replaced, or obsoleted by other documents at any draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:63: to this document. Code Components extracted from this document must draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:68: This document may contain material from IETF Documents or IETF draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:71: material may not have granted the IETF Trust the right to allow draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:74: the copyright in such materials, this document may not be modified draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:75: outside the IETF Standards Process, and derivative works of it may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:494: client and server that support minor version X must support minor draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:495: versions 0 through X-1") and 12 ("no new features may be introduced draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:608: resources. The client may be an application that contains the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:609: logic to access the NFS server directly. The client may also be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:628: Note that multiple clients may share the same transport and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:629: connection and multiple clients may exist on the same network draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:639: may share a client owner. The server is expected to treat draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:650: lease period, locks may be revoked if the lease has not been draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:651: extended. A lock must be revoked if a conflicting lock has been draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:740: that is expected. The reader should be familiar with the External draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:760: other mechanisms may also be specified and used for NFSv4.1 security. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:764: about its policies regarding which security mechanisms must be used draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:806: specified by the layout via a data storage protocol which may be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:807: NFSv4.1 or may be another protocol. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:902: information that specifies how the client may access that file draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:915: These file system location attributes may be used together with the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:921: o These attributes may be used with absent file systems to implement draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:922: referrals whereby one server may direct the client to a file draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:926: o These attributes may be provided when a previously present file draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:966: direct access to the file data may be performed directly by the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:968: inconsistent with that access may be made so long as the layout is draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1036: o In NFSv4.1, LIPKEY and SPKM-3 are not required security mechanisms draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1060: and required a host-based authentication approach. NFSv4.1 also draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1197: or server, so there is some due diligence required by the user of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1278: initializes, and may change when the server re-initializes. Client draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1298: EXCHANGE_ID) is required to establish and confirm the client ID on draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1339: o The string should be unique so that multiple clients do not draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1353: o The string should be selected so that subsequent incarnations draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1361: o The string should be the same for each server network address that draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1367: o The algorithm for generating the string should not assume that the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1391: should be performed). draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1410: o For a user-level NFSv4.1 client, it should contain additional draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1416: EXCHANGE_ID) and should be chosen so that it will not conflict with a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1420: In the event of a server restart, a client may find out that its draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1441: This session will be associated with the existing client ID but may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1473: To facilitate upgrade from NFSv4.0 to NFSv4.1, a server may compare a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1483: client ID that prevents trunking, it should send two EXCHANGE_ID draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1599: reader is cautioned that multiple servers may deliberately or draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1601: so_minor_id; the reader should examine Sections 2.10.5 and 18.35 in draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1616: NFS server may have multiple points within its file system namespace draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1629: server may be configured such that each of these security policy draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1630: boundaries may have different or multiple security mechanisms in use. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1635: server to choose a lower level of security than required or desired. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1653: However, the server's policies may also change at any time and force draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1660: access should be presented first. Where the general level of access draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1664: principals should be listed first. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1672: the server, the client may receive an NFS error of NFS4ERR_WRONGSEC. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1728: supports may differ from those of the child. The server draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1729: implementation may decide whether to impose any restrictions on draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1753: child directory may not intersect with that of the parent. In draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1755: administrator may set up these tuples. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1760: when there is a security tuple mismatch. Instead, it should be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1764: Since the above guideline does not contradict approach (a), it should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1816: policy. But in practice, the client may start looking for strong draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1861: used does not match that required for the target file. By rule (see draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1926: minor versions. Note that a future minor version may modify or add draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1934: 2. Minor versions may add operations to the COMPOUND and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1940: * Minor versions may append attributes to the bitmap4 that draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1947: * Minor version X must append any new attributes after the last draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1955: 3. Minor versions must not modify the structure of an existing draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1966: for a single operation is too burdensome. New operations should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1986: 4. Minor versions must not modify the structure of existing draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1989: 5. Minor versions must not delete operations. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1994: 6. Minor versions must not delete attributes. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1996: 7. Minor versions must not delete flag bits or enumeration values. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:1998: 8. Minor versions may declare an operation MUST NOT be implemented. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2008: 1. Minor versions may declare that an attribute MUST NOT be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2011: 2. Minor versions may declare that a flag bit or enumeration draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2021: 9. Minor versions may downgrade features from REQUIRED to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2024: 10. Minor versions may upgrade features from OPTIONAL to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2030: 12. Except for infrastructural changes, a minor version must not draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2083: acl and sacl attributes as described in Section 6. Alarms may serve draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2201: The reply cache may be used when a connection within a session is draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2203: a dynamic property of the RDMA connection, and stale values must draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2205: contents must not be blindly used when replies are sent from it, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2206: and credit information appropriate to the channel must be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2215: registered port 2049 [41] for the NFS protocol should be the default draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2284: exists whether or not the connection exists. A client may have one draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2286: may be accessed using any of the sessions associated with that draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2304: A single client may create multiple sessions. A single session MUST draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2319: NFSv4.1 defines the SEQUENCE operation, which is required for every draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2330: particular session. SEQUENCE also contains required information for draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2368: A client ID and associated session are required to perform file draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2436: connection associated with the channel(s) of one session may be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2474: set may be presented to another server of the same scope. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2492: server owner value may be validly compared. In cases where the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2496: The coordination among servers required to provide such compatibility draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2513: necessity for the client to determine when lock reclaim should be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2538: o The client may accept the appearance of the second server in the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2543: system may be used. The client sends the GETATTR request to the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2545: with RPCSEC_GSS authentication. It may need to do this in advance draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2550: scope is supported. A client may choose to limit the use of this draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2569: Clients may use either form of trunking as long as they do not, when draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2641: it is not required to do so. It can invoke CREATE_SESSION on the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2671: may be different on subsequent EXCHANGE_ID requests made to the same draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2693: may assume that the probability of inadvertent acceptance is low draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2707: trunking. This may result in connections being dropped or new draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2715: servers' claims. The client may verify these claims before trunking draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2824: Therefore, EOS is required for non-idempotent requests. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2876: The RPC layer provides a transaction ID (XID), which, while required draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2886: there is no bound on the number of requests that may be outstanding draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2903: section. The slot ID must be unused by any of the requests that the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2980: the required entries for an effective reply cache. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:2999: o The requester and replier must be able to interoperate at the RPC draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3007: o The SEQUENCE or CB_SEQUENCE operation may generate an error. If draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3012: Given that well-formulated XIDs continue to be required, this raises draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3037: value. The requester should in all cases provide the most draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3052: other requesters. The requester must always comply with the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3055: However, because of request pipelining, the requester may have draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3057: replier must not immediately require the requester to comply. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3112: new request. This way, the replier may be able to retire slot draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3116: the slot ID nor the highest_slotid used in a request may reflect draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3118: because the request may have been sent from the requester before draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3120: case, the replier may have to retain a number of reply cache draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3155: request. Therefore, it may be the case that highest slot ID, target draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3156: slot ID, or status bits may reflect the state of affairs when the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3158: information is valid, it may cause the receiver of the reply to do draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3179: Caching the reply may offer little benefit. If the reply is too draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3180: large (see Section 2.10.6.4), it may not be cacheable anyway. Even draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3202: to cache. It may choose this approach in order to simplify draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3241: Since the replier may only cache a small amount of the information draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3242: that would be required to determine whether this is a case of a false draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3243: retry, the replier may send to the client any of the following draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3285: the replier, should be applied before determining whether the users draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3352: operations become invalid after connection loss. The server must draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3353: ensure that any RDMA operations that must be replayed from the reply draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3378: client may have been granted a delegation to a file it has opened, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3380: the delegation) may be delayed in the network. If a conflicting draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3382: the backchannel, which may be on a different transport connection, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3428: The client must not simply wait forever for the expected server reply draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3431: client should assume the likely case that the reply will arrive draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3435: are other scenarios under which callbacks may race replies. Among draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3440: Very large requests and replies may pose both buffer management draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3486: server may return NFS4ERR_REP_TOO_BIG_TO_CACHE on the tenth draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3658: Following basic registration, these buffers must be posted by the RPC draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3660: NFSv4.1 implementation; the size and number of them must be known to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3684: channel(s) must remain. RDMA connections are managed within these draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3701: The limits may also be modified dynamically at the replier's choosing draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3739: therefore minimal buffer size. The client must select its offered draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3765: In the above case, the server may recycle unused buffers to the next draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3766: posted receive if unused by the actual received request, or may pass draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3771: and integrated server designs, among many others. The client may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3842: from releasing state when RPCSEC_GSS is required to do so, but a GSS draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3876: namespace require RPCSEC_GSS authentication, a client may have to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:3878: LOCKU, CLOSE, etc.). The server may require that the principal draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:4349: special care must be taken by the implementation of the NFSv4.1 draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:4437: because sessions consume resources, and resource limitations may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:4500: the client MUST tell the server what security is required in order draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:4623: After an event like a server restart, the client may have lost its draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:4637: not want to take advantage of such features as trunking, it may omit draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:4678: be unable to provide NFSv4.1 service, and fatal errors should be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:4687: unable to provide NFSv4.1 service, and fatal errors should be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:4698: reconfiguration. Nonetheless, clients should not assume that servers draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:4738: recovery may still be needed. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:4775: To the server, the extended network partition may be no different draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5192: undefined. The server is required to increment the "seqid" field by draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5270: communicate with the NFSv4.1 storage devices, and may be sufficient draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5338: in Section 5.12.4. The metadata server may ignore the hint or may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5339: selectively ignore fields within the hint. This hint should be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5360: respectively. The metadata server's use of the iomode may depend on draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5399: helping the client determine when it should send I/O directly through draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5402: describing the set of hints supported by the server (they may differ draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5531: ROOT filehandle, the PUBLIC filehandle may be bound or represent an draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5533: responsible for this binding. It may be that the PUBLIC filehandle draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5537: PUBLIC filehandle and server file system object. The client may not draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5563: file system may not provide the invariant or the server's file system draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5564: programming interfaces may not provide access to the needed draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5565: invariant. Volatile filehandles may ease the implementation of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5571: filehandles differently, a file attribute is defined that may be used draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5585: filehandles and files, but this is not required. Clients MUST use draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5625: an error of NFS4ERR_STALE. A filehandle may become stale when the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5627: system may become unavailable if it exists on removable media and the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5635: characteristics of a persistent filehandle. The server may determine draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5639: server should return NFS4ERR_STALE to the client (as is the case for draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5642: should return an error of NFS4ERR_FHEXPIRED. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5664: FH4_VOLATILE_ANY The filehandle may expire at any time, except as draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5677: information should assume that filehandles will expire on file draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5689: different handle class. In these cases, the server should deny a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5691: components leading to the OPEN file. In addition, the server should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5693: to make sure that reclaims of files where filehandles may have draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5739: NFS4ERR_FHEXPIRED error. The client must take on additional draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5740: responsibility so that it may prepare itself to recover from the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5747: object in question. With these names, the client should be able to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5760: the file is open, it is possible that the client may be able to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5799: in the response. New REQUIRED or RECOMMENDED attributes may be added draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5836: server should support as many of the RECOMMENDED attributes as draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5837: possible but, by their definition, the server is not required to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5844: for protocol processing. The client should not make any assumptions draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5856: REQUIRED attributes some client functionality may be impaired or draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5857: limited in some ways. A client may ask for any of these attributes draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5864: NFSv4.1 protocol. However, they may not be supported on all clients draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5865: and servers. A client may ask for any of these attributes to be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5866: returned by setting a bit in the GETATTR request but must handle the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5869: attributes the server does not support. A server should be tolerant draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5874: operating environments. A server should provide attributes whenever draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5876: modification time should be either an accurate time or should not be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5895: the file system object. The namespace for these attributes may be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5898: further perusal and modification of the namespace may be done using draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5900: READDIR may be used to get a list of such named attributes, and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5901: LOOKUP and OPEN may select a particular attribute. Creation of a new draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5902: named attribute may be the result of an OPEN specifying file draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5905: Once an OPEN is done, named attributes may be examined and changed by draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5909: Named attributes and the named attribute directory may have their own draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5911: REQUIRED attributes and may have additional RECOMMENDED attributes. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5923: client should not depend on the ability to store any named attributes draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5925: attributes, a client that is also able to handle them should be able draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5949: named attributes. Further, directories may not be created in a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:5977: possible that some per file system attributes may vary within the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6039: likely authoritative, but should be resolved with Errata to this draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6054: may retrieve, SETATTR may not set). W means write-only (SETATTR draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6055: may set, GETATTR may not retrieve). R W means read/write (GETATTR draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6056: may retrieve, SETATTR may set). draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6239: modified. The server may return the object's time_metadata attribute draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6369: object -- this should be the smallest relevant limit. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6374: should be the smallest relevant limit. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6395: Locations where this file system may be found. If the server returns draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6512: should obey an invariant that has it returning a value that is equal draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6543: understood that this space may be consumed by allocations to other draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6561: may reasonably be warned. It is understood that this space may be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6574: Note that there may be a number of distinct but overlapping sets of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6578: when providing the content of the quota_used attribute, but should do draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6579: so in a repeatable way. The rule may be configured per file system draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6580: or may be "choose the set with the smallest quota". draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6592: containing this object -- this should be the smallest relevant limit. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6597: this should be the smallest relevant limit. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6635: server should make its best efforts to record time_access into stable draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6702: Similarly, security principals may be represented in different ways draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6713: be employed. For example, a local translation table may be consulted draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6715: service may also be used to accomplish the translation. A server may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6727: storage without any translation or it may augment a translation draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6742: that contain aliasing) may make that promise impossible to honor. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6743: Servers should make appropriate efforts to avoid a situation in which draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6748: domain name, for example, user@example.org. Servers should accept as draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6749: valid a set of users for at least one domain. A server may treat draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6759: and that the receiver of the attribute should not use that string as draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6761: the attribute value cannot be translated, it may still be useful. In draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6762: the case of a client, the attribute string may be used for local draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6770: support. The receiver may treat such a user or group string as draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6781: obligated to accept such a string, but may return an NFS4ERR_BADOWNER draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6786: designated in this way. In that case, the client must use the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6790: The owner string "nobody" may be used to designate an anonymous user, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6811: and asks for attribute change notifications, it should request draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6853: to files on that file system. Where possible, the client should send draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6861: to files on that file system. Where possible, the client should send draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6868: The layout_hint attribute (see Section 3.3.19) may be set on newly draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6872: server may choose to ignore this attribute. The layout_hint draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6916: should be sent to the metadata server, while a value of all ones draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6917: indicates that all READs or WRITEs should be sent to the metadata draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6922: server should return an attribute that is representative of the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6925: changes, the client should not assume that the attribute will remain draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:6926: constant for any specific time period; thus, it should be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7094: and their interactions. Note that file attributes may apply to any draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7103: o If a server supports the mode attribute, it should provide draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7107: o If a server supports ACL attributes, it should provide reasonable draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7119: behavior should be traditional UNIX-like behavior. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7125: * Setting only the mode attribute should effectively control the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7129: * Setting only the mode attribute should provide reasonable draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7130: security. For example, setting a mode of 000 should be enough draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7136: o NFSv4.1 may introduce different semantics relating to the mode and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7143: attributes, the server must keep the two consistent with each draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7145: three high-order bits described in Section 6.2.4) must be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7147: mode is never required for anything other than setting the three draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7150: o When a mode attribute is set on an object, the ACL attributes may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7208: The NFSv4.1 ACL model is quite rich. Some server platforms may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7212: server may support the acl attributes by mapping between its ACL draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7213: model and the NFSv4.1 ACL model. Servers must ensure that the ACL draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7220: should accept every ACL that they can without compromising security. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7229: To help accomplish this, servers may make a special exception, in the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7231: ALLOWED or DENIED by an ACL must be denied. For example, a UNIX- draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7235: attributes should still be rejected.) draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7237: The situation is complicated by the fact that a server may have draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7239: NFSv4.1 access may be different from, but not weaker than, the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7240: enforcement for local access, and both may be different from the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7242: Message Block). So it may be useful for a server to accept an ACL draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7246: must not accept ACLs that appear to make access to the file more draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7258: Only the ALLOWED and DENIED bits may be used in the dacl attribute, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7259: and only the AUDIT and ALARM bits may be used in the sacl attribute. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7341: Clients should not attempt to set an ACE unless the server claims draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7348: Support for any of the ACL attributes is optional (albeit draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7570: reading the contents. Though a server may treat ACE4_EXECUTE draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7643: operation requests attributes, this mask must be allowed for draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7797: implement, it should err in the direction of more restricted access, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7802: ACE4_WRITE_DATA is not (or vice versa), the server should either turn draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7824: permitted. In the case where MODE4_SVTX is set, the server may also draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7825: require the remover to own either the parent or the target, or may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7856: the implementation may define a mapping between the protocol-defined draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7862: should reject the request with NFS4ERR_ATTRNOTSUPP. If the server draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7864: directories, the server may reject the request (i.e., requiring the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7866: server may also accept the request and silently turn on the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7876: Can be placed on a directory and indicates that this ACE should be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7884: inheritance of this ACE should stop at newly created child draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7914: ACE4_FAILED_ACCESS_ACE_FLAG (FAILED) flag bits may be set only on draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7948: attribute; it may only be used in the dacl and sacl attributes. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7960: principal or principals to whom the ACE applies. It may refer to a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:7990: appended "@" and should appear in the form "xxxx@" (with no domain draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8078: then neither the acl nor the dacl attribute should be automatically draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8113: o In the case of a file system exported as read-only, the server may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8137: the ACL. This may be helpful, for example, to allow users draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8142: beyond an ordinary user. The superuser may be able to read or draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8154: results of having the server determine whether or not access should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8157: Clients must be aware of situations in which an object's ACL will draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8163: determine whether the user or application should be granted the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8164: access requested. For examples in which the ACL may define accesses draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8210: DENY ACEs may also lead to such behavior, but DENY ACEs are expected draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8220: The server that supports both mode and ACL must take care to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8255: explicitly set, the acl and dacl attributes must be modified in draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8256: accordance with the updated value of those bits. This must happen draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8298: Also note that the requirement may be met by discarding the acl and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8329: Some server implementations may have a concept of "objects without draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8356: If a server supports any ACL attributes, it may use the ACL draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8364: Implementors should standardize what the behavior of CREATE and OPEN draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8365: must be depending on the presence or absence of the mode and ACL draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8405: empty ACL denies all permissions, but the server should allow the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8427: If the object being created is a directory, the inherited ACL should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8473: and all other bits must be cleared. The ACE4_INHERITED_ACE flag may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8474: be set in the ACEs of the sacl or dacl (whereas it must always be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8493: A client application such as an ACL editor may then propagate changes draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8499: which ACEs to propagate. (Note that it may encounter further draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8504: The reach of this propagation may be limited in two ways: first, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8521: attributes; thus, the ACL4_AUTO_INHERIT and ACL4_PROTECTED flags may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8523: one type of acl may continue down a hierarchy even where propagation draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8526: New objects should be created with a dacl and a sacl that both have draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8531: Both the dacl and sacl attributes are RECOMMENDED, and a server may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8535: the new dacl or sacl attributes must do so in such a way as to keep draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8537: reported in the acl attribute should be the union of the ACEs draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8539: ACE4_INHERITED_ACE flag must be cleared from the ACEs in the acl. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8546: attributes, the client signals that it may not understand automatic draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8551: again, it should leave any ACEs marked with ACE4_INHERITED_ACE draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8553: application is unable to do this, it should set the ACL4_PROTECTED draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8555: this rule may lead to unexpected results when applications perform draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8578: sign that the ACL should be completely replaced by one generated draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8584: server namespaces may be presented directly to clients, or they may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8611: through a directory tree. The client must be able to move from one draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8650: reach actual exported file systems. A technique that servers may use draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8657: that multiple pseudo file systems may exist. For example, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8691: that the pseudo file system may not have an on-disk counterpart from draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8694: pseudo file system, the NFS client should expect that pseudo file draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8697: question. If the filehandles are volatile, the NFS client must be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8716: LOOKUPs. The server must bridge the gap with a pseudo file system. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8720: The server file system environment may be constructed in such a way draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8727: The pseudo file system for this server may be constructed to look draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8757: Instead, it should present a consistent view and return draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8776: server should apply the same security policy to /a/b. This allows draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8803: clients should use strong security mechanisms to access the pseudo draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8834: stateids may represent a particular open file, a set of byte-range draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8855: A client must establish a client ID (see Section 2.4) and then one or draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8879: stateids by which they may be referenced. The stateid is used as a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8883: filehandle. When stateids are used, the current filehandle must be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8891: The server may assign stateids independently for different clients. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8892: A stateid with the same bit pattern for one client may designate an draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8896: the given client ID, and the client may use a stateid obtained from draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8918: o Stateids may represent opens of files. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8926: o Stateids may represent sets of byte-range locks. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8933: o Stateids may represent file delegations, which are recallable draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8936: returned. In NFSv4.1, file delegations may be obtained on both draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8942: o Stateids may represent directory delegations, which are recallable draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8949: o Stateids may represent layouts, which are recallable guarantees by draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8950: the server to the client that particular files may be accessed via draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8952: access is limited to particular sets of byte-ranges and may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:8987: modify the set of locks, the server is required to increment the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9005: sent. It may set the seqid to zero to indicate to the server that it draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9008: sent with a READ or WRITE operation. It also may set a non-zero draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9010: one. In that case, the server is required to return draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9022: with a CLOSE or OPEN_DOWNGRADE. Because OPENs may be sent in draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9034: sent by the server to the client as part of a callback is required to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9052: are reserved. They may not be assigned by the server but have draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9119: Stateids must remain valid until either a client restart or a server draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9138: It should be noted that there are situations in which the client's draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9145: An "other" value must never be reused for a different purpose (i.e., draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9147: a single client ID. A server may retain the "other" value for the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9148: same purpose beyond the point where it may otherwise be freed, but if draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9149: it does so, it must maintain "seqid" continuity with previous values. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9151: One mechanism that may be used to satisfy the requirement that the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9224: stateid is used when an OPEN stateid is required in a LOCK draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9263: may be valid in general, as would be reported by the TEST_STATEID draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9279: o Otherwise, the stateid is valid and the table entry should contain draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9322: Ignoring these rules may result in situations in which the server draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9328: The server however should not try to enforce these ordering rules and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9329: should use whatever information is available to properly process I/O draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9338: stateid for the server to be able to determine whether they should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9343: other than those that set the file size, the client may send either a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9346: stateid and may use the stateid to optimize the determination as to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9371: consistency and lease renewals may not be denied if the lease draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9392: should also take communication-related delays into account and take draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9396: o When trunking is in effect, the client should consider sending draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9402: approach or exceed the length of the lease period. This may be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9448: lease, and because it must be done at least once for each lease draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9451: informed of. The client should inspect the status flags draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9457: backchannel that the client may need to address in order to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9479: revocation events. When these bits are set, the client should use draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9488: due to server restart the client must reclaim locking state. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9499: required that a client sees a consistent view of data across server draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9500: restarts. All READ and WRITE operations that may have been queued draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9501: within the client or network buffers must wait until the client has draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9505: sure that such operations can be safely processed must be rejected. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9514: o Subsequent recovery of locks may make execution of the operation draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9527: In the event that a client fails, the server may release the client's draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9529: another client may only be granted after this lease expiration. As draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9557: Note that the verifier must have the same uniqueness properties as draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9563: it must allow clients time to discover this fact and re-establish the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9564: lost locking state. The client must be able to re-establish the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9570: example, if mandatory locks are a possibility, the server must draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9585: NFS4ERR_BADSESSION, this may mean that the session has been draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9589: the client must establish a new client ID (see Section 8.1) and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9600: with NFS4ERR_STALE_CLIENTID, the client must establish a new draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9613: of a server restart, the protocol must provide a way to cause that draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9622: Because each client must have an opportunity to reclaim all of the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9641: made, the server must return the error NFS4ERR_GRACE. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9651: client sends such a RECLAIM_COMPLETE operation, it may attempt non- draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9658: During the grace period, the server must reject READ and WRITE draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9661: guarantee that these may be done safely, as described below. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9663: The grace period may last until all clients that are known to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9667: has done a RECLAIM_COMPLETE must be prepared to receive an draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9670: done a RECLAIM_COMPLETE, the server must maintain in stable storage a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9671: list clients that may have such locks. The server may also terminate draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9683: client ID and session and to effect lock reclaims may be added to the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9699: grace period, although NFS4ERR_GRACE must always be returned to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9702: and WRITE operations during the grace period, it must again be able draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9706: error must be returned to the client. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9711: NFS4ERR_GRACE error. However, a server may keep information about draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9721: specify deny modes may be safely granted. If, in addition, it is draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9724: does not support such locks, READ and WRITE operations may be safely draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9730: operations may be validly processed during the grace period because draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9749: Clients should be prepared for the return of NFS4ERR_GRACE errors for draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9750: non-reclaim lock and I/O requests. In this case, the client should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9752: several seconds) between retries should be used to avoid overwhelming draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9754: [54]. The client must account for the server that can perform I/O draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9762: A server may, upon restart, establish a new value for the lease draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9763: period. Therefore, clients should, once a new client ID is draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9766: However, the server must establish, for this restart event, a grace draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9775: and when the client should attempt to reclaim locks previously draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9779: o If the server scope is different, the client should not attempt to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9787: o If the server scope is the same, the client should attempt to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9850: lease renewal from the client. If this occurs, the server may free draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9851: all locks held for the client or it may allow the lock state to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9867: conflict, it may either free all of the client's locks once there is draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9868: a conflict or it may only revoke the minimum set of locks necessary draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9870: approach, it must revoke all locks associated with a given stateid, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9875: to obtain a conflicting a lock, the server may report the loss of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9878: The server may choose to invalidate the session and the associated draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:9897: invalidated locks. The client should then take action to free draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10032: o a boolean that indicates whether the client may have locks that it draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10044: range lock, share reservation, or delegation. Hence, the server must draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10050: must reject a reclaim from client A with the error NFS4ERR_NO_GRACE. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10087: stable storage, then for all clients and/or locks that may be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10105: discussion of what the client should do for dealing with unreclaimed draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10113: client must be prepared for this event. When the client detects that draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10114: its locks have been or may have been revoked, the client is draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10117: must verify or reclaim state for each lock currently held. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10129: is considered a rare or unusual event, the client must be prepared to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10150: are possible, and the client must be prepared to deal with them. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10157: In all situations in which a subset of locking state may have been draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10177: After server failure, a longer grace period may be required when some draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10207: To take propagation delay into account, the client should subtract it draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10212: server. So the client must send a lease renewal or write data back draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10219: The server's lease period configuration should take into account the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10225: server's administrator may have to tune the lease period. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10299: LOCK operation contains the heavyweight information required to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10314: When opening a file or requesting a byte-range lock, the client must draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10319: the owner of a lock managed by the client. This may be a thread ID, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10343: operations must be one that represents an open, a set of byte-range draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10344: locks, or a delegation, or it may be a special stateid representing draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10350: (previously returned by the server) must be used to indicate what draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10372: with error NFS4ERR_LOCKED. Byte-range locks may be implemented by draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10374: mandatory or advisory behavior may be determined by the server on the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10377: that if set, byte-range locks are required on the file before I/O is draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10444: case of READ, the server may perform the corresponding check on the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10445: access mode, or it may choose to allow READ on OPENs for draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10447: implementation may unavoidably do reads (e.g., due to buffer cache draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10465: A lock may not be granted while a READ or WRITE operation using one draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10512: systems may not be able to support sub-range lock semantics. In the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10517: should be prepared to receive this error and, if appropriate, report draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10522: server may not support sub-range requests for reasons related to the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10524: As discussed in Section 8.4.2, the server may employ certain draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10543: NFS4ERR_LOCK_NOTSUPP. The client should be prepared to receive this draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10555: WRITEW_LT and the server has detected a deadlock. The client should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10589: stateids, and so a situation may arise in which there are multiple draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10620: the server should maintain an ordered list of pending blocking locks. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10621: When the conflicting lock is released, the server may wait for the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10624: waiting client request is allowed the lock. Clients are required to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10626: the lock in a timely manner. The server is not required to maintain draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10629: recovery, storing of lock state to stable storage would be required draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10632: Servers may also note the lock types and delay returning denial of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10645: The server should take care in the length of delay in the event the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10650: denied, then it should remove the lock in question from its list of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10651: pending blocking locks. Clients should use such a nonblocking draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10653: intend to poll for the lock, as may happen when the process draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10657: required to perform this courtesy, and servers must not depend on draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10658: them doing so. Also, clients must be prepared for the possibility draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10663: file, the client should take notice of this, but, since this is a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10665: may reasonably reduce the frequency with which it polls for a denied draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10668: it receives a CB_NOTIFY_LOCK, it should promptly try to obtain the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10669: lock, but it should be aware that other clients may be polling and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10678: specifying the type of access required (READ, WRITE, or BOTH) and the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10732: to use a special stateid for anonymous state or READ bypass, it must draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10736: for opening a file should request a deny mode of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10746: free all outstanding locks on CLOSE, but some servers may not support draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10781: the occurrence of the upgrade. The increment is required in cases in draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10785: the effects of both OPENs. The client may use the stateid returned draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10789: the client, when sending the OPEN, may not know that the same file is draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10797: Instead, the server must maintain separate OPENs with separate draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10802: client) may necessitate change of the access and deny status of the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10804: deny bits for the remaining opens may be smaller (i.e., a proper draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10814: make the necessary change and the client should use it to update the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10825: seqid, multiple OPENs for the same open-owner may be done in draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10826: parallel. When clients do this, they may encounter situations in draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10828: may turn out to open the same file, with a later OPEN performed being draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10832: In this situation, clients may determine the order in which the OPENs draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10840: for the same open-owner in parallel, it may be the case that an open draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10841: upgrade may happen without the client knowing beforehand that this draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10843: OPEN_DOWNGRADEs should generally be sent with a non-zero seqid in the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10934: large penalty is incurred. This penalty may discourage the use of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10968: stateid for a delegation is associated with a client ID and may be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10982: BIND_CONN_TO_SESSION, and the client is required to maintain it. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10983: Because the backchannel may be down, even temporarily, correct draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10998: such operations are required to effect a recall. A number of points draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:10999: should be noted, however. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11002: desirable and may do so even if no operations requiring recall are draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11014: delegation recall is required. If a particular change within a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11016: delegation recall is required, whether that operation has been draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11023: required under some common circumstances: draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11058: At the time the client receives a delegation recall, it may have draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11060: the server should allow sufficient time for the delegation to be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11061: returned since it may involve numerous RPCs to the server. If the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11063: state to the server as a result of the recall, the server may extend draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11065: recall completion should not be unbounded. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11099: Delegations, however, may be treated a bit differently. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11103: client may have file data stored locally and this data was associated draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11111: process may require significant time for the client to flush changed draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11135: delegation should not be granted, it performs the requested action draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11153: earlier server instance must be granted those resources. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11159: o The use of callbacks should not be depended upon until the client draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11163: associated open, the client may use the CLAIM_PREVIOUS variant of the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11164: WANT_DELEGATION operation. However, since the server is not required draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11180: however, the server may extend the period in which conflicting draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11190: NFS4ERR_DELEG_REVOKED. It also may find out about delegation draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11194: may have been modified by the client whose delegation is revoked and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11222: caching must be implemented such that it does not invalidate the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11228: applications rely, NFSv4.1 clients should not provide cached data to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11237: o First, cached data present on a client must be revalidated after draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11243: client's cache. This validation must be done at least when the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11246: clients may have had the opportunity to open the file with draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11248: may choose to do the revalidation more often (i.e., at OPENs draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11262: modifications, some client implementors may be tempted to use the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11274: o Second, modified data must be flushed to the server before closing draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11279: close is that the data must be committed to stable storage, at the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11281: the case of a server restart and a CLOSEd file, it may not be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11302: file system. However, they may not work with the NFSv4.1 protocol draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11317: any cache data exists) must be revalidated. If the change draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11318: attribute indicates that the file may have been updated since the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11319: cached data was obtained, the client must flush or invalidate the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11326: modified data for that byte-range must be flushed to the server. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11327: The modified data must also be written to stable storage. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11330: data must reflect the actual byte-ranges locked or unlocked. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11334: unlocked may cause invalid modification to the byte-range outside the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11335: unlocked area. This, in turn, may be part of a byte-range locked by draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11342: client possesses may not be valid. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11345: unlocking of a byte-range must be written, at the server, to stable draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11346: storage. The client may accomplish this either with synchronous draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11348: This is required because retransmission of the modified data after a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11351: A client implementation may choose to accommodate applications that draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11354: a LOCKU than is covered by the locked range. This may include draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11356: are being done. In such cases, the client must not interfere with draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11377: byte-range lock. Any writes done for the former class of files must draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11387: effect for a file, the client must check for an appropriate byte- draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11389: exists for the range being read or written, the client may satisfy draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11392: read or write request must not be satisfied by the client's cache and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11393: the request must be sent to the server for processing. When a read draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11395: should be subdivided into multiple pieces with each byte-range draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11409: because a filehandle may be constructed on the basis of the object's draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11461: When a file is being OPENed, the server may delegate further handling draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11465: receives a conflicting OPEN from another client, the server must draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11467: client may be granted. Making a delegation is up to the server, and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11468: clients should not assume that any particular OPEN either will or draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11471: should be delegated: draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11473: o The client must be able to respond to the server's callback draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11485: o The client must have responded properly to previous recalls. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11487: o There must be no current OPEN conflicting with the requested draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11490: o There should be no current delegation that conflicts with the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11493: o The probability of future conflicting open requests should be low draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11497: would make the required handling incompatible with the prescribed draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11504: OPEN_DELEGATE_READ delegations may be outstanding simultaneously and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11507: delegation may exist for a given file at a given time, and it is draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11514: client has an OPEN_DELEGATE_WRITE delegation, it may modify the file draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11516: The client holding an OPEN_DELEGATE_WRITE delegation may only locally draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11519: other attributes must be reflected on the server. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11522: or CLOSEs to the server. Instead, the client may update the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11526: OPEN4_SHARE_ACCESS_READ access) must be sent to the server. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11557: checks to be made by the delegate should result in the OPEN draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11567: ACCESS calls. The permission check should be as follows: draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11569: o If the nfsace4 indicates that the open may be done, then it should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11572: o If the nfsace4 indicates that the open may not be done, then an draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11573: ACCESS request must be sent to the server to obtain the definitive draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11576: The server may return an nfsace4 that is more restrictive than the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11580: Section 5.9) may make it incorrect to return the actual ACL of the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11588: client should be sure authentication and authorization occurs for draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11597: each user by use of the ACCESS operation. This should be the case draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11598: even if an ACCESS operation would not be required otherwise. As draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11599: mentioned before, the server may enforce frequent authentication by draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11625: delegation must be recalled and I/O not proceed until the delegation draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11642: block size. The server must ensure that the client will be able to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11644: the original delegation. The server must make this assurance for all draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11653: outstanding delegations. Therefore, the server must be careful in draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11657: available file system space. The client should abide by the server's draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11662: the server may grant OPEN_DELEGATE_WRITE delegations with very draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11663: restrictive space limitations. The limitations may be defined in a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11668: after a CLOSE has occurred may be problematic. For example, the user draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11669: of the application may have logged off the client, and unexpired draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11670: authentication credentials may not be present. In this case, the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11671: client may need to take special care to ensure that local unexpired draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11672: credentials will in fact be available. This may be accomplished by draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11680: operations are performed locally. This includes those required for draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11697: OPEN_DELEGATE_WRITE delegation may have modified the data, and the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11751: d may always be c + 1. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11807: CB_GETATTR calls. Therefore, the server must assume that the file draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11857: It should be noted that the server is under no obligation to use draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11885: when a file is open, the recall must be performed to determine draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11888: In addition to the situations above, the server may choose to recall draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11890: advisable to do so. Clients should always be prepared for the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11895: same updates must be done whenever a client chooses to return a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11901: operation must be sent to the server. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11904: operations must be sent to the server. The appropriate stateids draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11919: OPEN4_SHARE_ACCESS_BOTH, all modified data for the file must be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11942: been propagated to the server, the truncation must occur before draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11947: associated invariant, it is required to flush any modified data in draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11959: the fact that the actual OPEN state of the file may continue to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11965: choices on scheduling these actions, all must be performed before the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11973: A client may fail to respond to a recall for various reasons, such as draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11975: may be unaware of a failure in the backchannel. This lack of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:11998: Whether the backchannel is functioning or not, it may be that the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12003: period of time should allow the client time to note the backchannel- draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12008: SEQUENCE operations. The client should note this and then use draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12014: on the client, these opens may or may not be revoked. If no byte- draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12016: open, the stateid for the open may remain valid and be disconnected draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12025: granted, then the existing OPEN must be revoked. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12035: file, the user of the application should be notified. Unfortunately, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12036: it may not be possible to notify the user since active applications draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12045: may not be present at the client. See Section 10.5.1 for additional draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12059: The WANT_DELEGATION operation may be performed on any type of file draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12088: must be removed from the client. In the case of modified data draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12089: existing in the client's cache, that data must be removed from the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12101: may have been granted a conflicting byte-range lock after the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12103: the data within the lock range may have been modified by the other draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12111: operations may not be returned, more drastic action such as signals draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12112: or process termination may be appropriate. The justification here is draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12113: that an invariant on which an application depends may be violated. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12116: logging, console messages, and GUI pop-ups may be appropriate. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12123: data to the server on each close must ensure that the user receives draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12125: revocation. Since such situations may require human action to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12127: or administrator is notified may be necessary. Logging and console draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12130: If there is modified data on the client, it must not be flushed draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12131: normally to the server. A client may attempt to provide a copy of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12137: may be of particular value for recovery. In another case, recovery draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12140: be anything but straightforward, so clients may avoid saving file draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12144: Saving of such modified data in delegation revocation situations may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12147: Such saving may also be restricted to situations when the client has draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12172: Clients may cache file attributes obtained from the server and use draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12175: means of requests to the server and should not be done locally and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12176: should not be cached. The exception to this are modifications to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12184: modified attributes may be returned to the server in reaction to a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12189: Changes made in one order on the server may be seen in a different draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12224: A client may validate its cached version of attributes for a file by draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12233: time_access value should fetch it with change during the attribute draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12236: The client may maintain a cache of modified attributes for those draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12250: SETATTR of time_access may alter the change attribute on the server. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12286: when page faults are not required, these attributes will not be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12293: file that a client is also accessing, the client may not be able draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12329: obligation may not be possible. A client MAY return stale draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12396: implemented, it may not always be functional because of resource draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12404: The results of LOOKUP and READDIR operations may be cached to avoid draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12406: attribute caching, inconsistencies may arise among the various client draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12417: expiration time for the associated name cache entries may be updated draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12449: When such serialization is not used, and there may be multiple draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12478: appropriately and correctly, the server must report the pre- and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12481: respect to the directory operation, the server must indicate that draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12483: atomically reported, the client should not assume that other clients draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12495: The results of READDIR operations may be used to avoid subsequent draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12497: caching, inconsistencies may arise among the various client caches. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12499: context of typical file system APIs, the following rules should be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12503: a single READDIR operation must always be a consistent snapshot of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12510: must revalidate the cached information. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12519: no other client modifications are occurring, the client may update draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12528: appropriately and correctly, the server must report the pre- and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12531: respect to the directory operation, the server must indicate that draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12533: atomically reported, the client should not assume that other clients draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12622: changing enough that the pure recall model may not be effective while draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12628: The delegation is read-only and the client may not make changes to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12641: clients may hold a delegation on the same directory, but if any such draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12676: is causing too many notifications to be sent out, it may decide to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12684: required under some common circumstances. In this regard, a similar draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12782: "server endpoint". Although using different connection types may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12796: to as session-trunkable. Note that two addresses may be server- draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12812: o Each server has a set of exported file systems which may be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12815: server, although the pseudo-fs may be dispensed with if there is draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12840: o A file system present in a server's pseudo-fs may have multiple draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12865: client may establish connections. There may be multiple endpoints draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12866: because a host name may map to multiple network addresses and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12867: because multiple connection types may be used to communicate with draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12887: numbers may be used in file system location entries to designate draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12902: contain a host name are resolved using DNS, and may result in one draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12953: may be accessed. As a result, file systems in the namespace of one draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12963: corresponding to a given file system may be found. This attribute draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12973: and if that should be necessary. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:12986: locations where the data corresponding to a given file system may be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13010: fs_locations_info attribute). There may also be an actual current draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13029: one possibility. A position in the namespace may be permanently draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13057: It should be noted that because the check for the current filehandle draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13079: attributes may be obtained for a filehandle within an absent file draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13092: attributes, they should be available at least to the same degree that draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13099: fsid: This attribute should be provided so that the client can draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13109: boundary between present and absent file systems. This value must draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13116: the present parent file system, there should be no need to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13120: systems, even when it is possible to provide them. The server should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13121: not assume that more information is always better and should avoid draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13144: Attributes for an absent file system may be fetched via a READDIR for draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13200: Under some circumstances, multiple replicas may be used draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13203: servers may be an impediment to such use. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13230: is OPTIONAL, a server may choose to take action to hide migration and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13238: relating to the location of multiple replicas which may be used in draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13244: instance may be accessed. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13254: replicas to access, the server should adhere to the following draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13258: system instance should be adjacent. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13261: in use should appear first. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13264: migration is occurring should appear before replicas which are draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13265: available for later use if the current replica should become draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13280: server in order to increase the speed of data transfer. A client may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13284: o When the name of the server is known to the client, it may use DNS draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13288: o The client may fetch the file system location attribute for the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13301: It should be noted that the client, when it fetches a location draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13302: attribute for a file system, may encounter multiple entries for a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13304: may have to bypass addresses not trunkable with one already known. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13313: The client may respond to such changes by using additional addresses draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13341: may have to choose a connection type with no possibility of changing draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13371: file system, the client should obtain the set of alternate locations draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13389: The alternate locations may be physical replicas of the (typically draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13391: propagation of updates. Alternatively, they may provide for the use draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13405: specificity, many applications may find use of migration more draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13413: In some situations, a file system location entry may indicate a file draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13432: used, trunking may be disallowed: draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13446: activity required on the part of the client. In this case, any draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13459: instance at all, must not treat any transition as a transparent draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13486: their data. This may involve use of a different access path to the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13564: The new location may be, in the case of various forms of server draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13572: may be provided. When multiple locations are provided, the client draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13582: it must designate the same data (with metadata being the same to the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13584: systems are writable, a change made on the original file system must draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13589: system must already be effected on all migration targets, to avoid draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13623: The file system location attribute may designate a single file system draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13626: attribute, may specify priorities to be associated with various file draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13627: system location choices. The server may assign different priorities draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13632: have to be in the case of replication and migration). Servers may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13639: multiple possible targets listed, the relationships among them may be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13651: required. The use of multi-server namespaces and their scope will draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13657: systems. Alternatively, a single multi-server namespace may be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13669: namespace. The top-level referral file system or any segment may use draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13690: in which case the value fetched may change over time. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13732: o When a new replica is added which may be accessed simultaneously draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13738: server may subsequently force such use to cease (by returning draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13768: that attribute should have the same value even if the interrogation draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13800: each principal, the same credential is required, independent of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13810: When AUTH_SYS is used, the following additional requirements must be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13816: o The "local" representation of all owners and groups must be the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13824: "local" representation of all owners and groups must be the same on draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13840: replication, and migration, care should be taken that a user who draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13844: file systems that may be on different servers. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13851: parent, it must go back to the parent as seen within the multi-server draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13862: are used extensively, they may change as server configurations draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13866: rooted in client-side name look up caching. Clients should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13870: referral entries themselves, clients should consider any associated draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13895: The endpoints used to access a particular file system instance may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13930: session will generally be accessible, there may be rare situations draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13940: to be discontinued, other server-trunkable addresses may be used draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13962: system. Some of these may involve an expansion or contraction of the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:13968: between the replicas may affect handling of the transition as draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14007: The fs_locations_info attribute (described in Section 11.17) may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14008: indicate that two replicas may be used simultaneously, although some draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14012: may be accessed simultaneously are somewhat similar to those in which draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14033: When there is no such replica, the transition may be to the replica draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14084: It is important to note that while clients themselves may have no draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14087: (e.g., via stat). The result is that an application may work draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14100: index to a given file may not be possible. Note here that a fileid draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14101: is not required to be useful to find the file in question, only that draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14118: should, and the client should be able to find out that such draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14133: read-only), problems for applications may occur. Therefore, use of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14134: such configurations should be limited to situations where the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14135: problems that this may cause can be tolerated. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14141: Clients should not make the fsids received from the server visible to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14142: applications since they may not be globally unique, and because they draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14143: may change during a file system transition event. Applications are draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14194: change class, the client may assume a continuity of change attribute draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14204: write verifiers returned from one system may be compared to those draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14208: verifier generated by one must not be compared to one provided by the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14209: other. Instead, the two verifiers should be treated as not equal draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14234: second, and must not be presented to that server by the client. The draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14235: client should act as if the verifier were rejected. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14261: fs_locations_info), they must designate the same data. Where file draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14262: systems are writable, a change made on one instance must be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14273: used. However, because the servers are not required to treat two draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14287: case of migration), the client may depend on the fact that all draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14295: of updates. They may need a guarantee that any change visible on draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14296: the original file system instance must be immediately visible on draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14320: server which may prevent actions by other clients that are draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14372: It should be noted that these two methods are not mutually exclusive draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14435: In the case of lease renewal, the client may not be submitting draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14443: is locking state that may have been relocated to the new server, the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14444: client must find out about lease relocation before that lease expire. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14461: locking state, the client should perform an operation. For draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14462: simplicity, the client may choose to reference all file systems, but draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14463: what is important is that it must reference all file systems for draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14472: A client may use GETATTR of the fs_status (or fs_locations_info) draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14475: cause an error in this context. However, it still must do an draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14492: In order that the client may appropriately manage its lease in the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14493: case of a file system transition, the destination server must draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14496: When state is transferred transparently, that state should include draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14498: attribute on the destination server must never be less than that on draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14510: refetch the lease_time attribute and may continue to use the value draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14516: new server, the client should fetch the value of lease_time on the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14518: requests. However, the server must respect a grace period of at draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14566: MDS function. Although the servicing of a layout may be transferred draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14597: Migration may transfer a file system from a server which does not draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14600: absence should check for pNFS support when a file system is migrated draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14606: For a client to respond to an access transition, it must become aware draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14622: should deal with each transition it becomes aware of, either directly draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14693: in the response to the same request. It should be noted that when draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14705: In this case, transition recovery is required. While it is draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14715: In this case, transition recovery is also required. It is clear draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14736: In this case, no transition recovery activity is required on the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14744: discovery is required. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14776: to be invoked as it is discovered. Alternatively, it may be done in draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14812: operating. One should not ignore a LEASE_MOVED indication if the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14816: lease-migrated indication may reflect the server's state at the time draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14817: the SEQUENCE operation was processed, which may be different from draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14819: migration events may occur at any time, and because a LEASE_MOVED draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14820: indication may reflect the situation in effect a considerable time draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14888: It should be noted that the process described above is not guaranteed draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14910: conflicting lock request may mean that a lock is revoked draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14911: unexpectedly. Clients should be aware of this possibility. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14979: has occurred may be invalidated and migration determined to have draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:14992: with it (clients may seek session-trunkable or server-trunkable draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15056: has taken place then the associated client ID may have already had a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15088: attempted Transparent State Migration, in which case state may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15135: To make a session available for use, a BIND_CONN_TO_SESSION should be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15137: fails, should a CREATE_SESSION be done. While this procedure mirrors draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15139: that preservation of the session is not purely optional but depends draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15282: destination must be aware of this loss so that it can deny a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15295: server should note these and not allow them to be reclaimed. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15315: issues discussed in Section 7.2 of [68] must still be attended to. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15316: In this case, the use of NFS4ERR_DELAY may still necessary in draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15359: o A single session may be used to access multiple file systems, not draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15362: o Requests made on a session may, even if rejected, affect the state draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15368: each of which is capable of changing session state, which may be of a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15385: It should be noted that the history of any particular slot is likely draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15388: migrated, requests of class 5 may be common and be the last request draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15414: migration, it may be necessary for the server to show some degree draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15424: it may not be necessary to adhere to this as strictly as might be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15426: fact that the error NFS4ERR_DELAY was returned may not assist the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15428: returned by the source server may not be relevant when the request draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15435: accessing a file system being migrated. Also, a COMPOUND may return draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15437: NFS4ERR_DELAY or NFS4ERR_MOVED, and may in addition be marked as draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15519: required behavior clear and easy to put within the scope of a small draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15527: may be for a number of reasons. It may be that the file system has draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15528: moved, or it may be that the target server is functioning mainly, or draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15724: Another context in which a client may encounter referrals is when it draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15882: namespaces, an array of server names may be provided. An entry in draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15893: for convenience. Servers that share the same rootpath may also be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15899: server may be constructed differently, the "fs_root" field is draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15979: locations should be assumed based on the following rules. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15984: o All listed file system instances should be considered as of the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:15992: o All listed file system instances should be considered as of the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16000: o All file system instances servers should be considered as of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16008: error, the target should be treated as being of the same write- draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16021: NFS4ERR_MOVED error, the target should be treated as being of a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16077: write), while others may only need access to the most up-to-date draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16110: It should be noted that fs_locations_info attributes returned by draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16111: servers for various replicas may differ for various reasons. One draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16112: server may know about a set of replicas that are not known to other draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16113: servers. Further, compatibility attributes may differ. Filehandles draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16214: As noted above, the fs_locations_info attribute, when supported, may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16225: The data presented in the fs_locations_info attribute may be obtained draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16245: attributes of the file system replica and should not be different draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16268: performed on the required schedule but instead serves as a hint draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16329: referenced in the XDR, the following practices should be followed draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16342: server is aware of the extension. This may be based on the length draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16379: writable, allowing it to be selected by clients that may need to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16383: client was previously writing, then it must incorporate within its draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16393: the request is being made. Only a single server entry may have draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16422: should not be used further. The client, if using it, should make draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16435: replica, or it may reference the current file system and only draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16447: current file system instance to this one, the replacement may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16460: directory filehandle associated with each open file, it may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16511: with the current one in a given respect, but the information should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16527: Servers may assign these values as they wish, so long as file system draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16565: with lower values indicating "more preferred". Clients should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16568: unavailable should the client proceed to those of a higher rank. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16570: should be conservative about using this mechanism, particularly when draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16585: all respects, clients should defer to the order specified by the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16589: specified order should guide selection. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16605: order should only be used if the client knows that only reading will draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16607: the event that any write access capability is required in the future. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16618: are not defined should always be returned as zero. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16648: particularly important when file system replicas may go out of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16650: communicate an ongoing change. The server should set draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16658: It is to be expected that this may have a different fli_valid_for draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16659: value, which the client should then use in the same fashion as the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16705: variable. The string "unknown" should be used by the client when it draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16708: different clients may have different file systems, corresponding to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16725: limit the acceptable values (except that they must be valid UTF-8 draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16732: (except that they must be valid UTF-8 strings), but such values as draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16739: does not limit the acceptable values (except that they must be valid draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16763: to substitute for various variables, clients should provide draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16770: context of referrals, it may be used in the context of replication draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16771: and migration. If it is used in these contexts, the server must draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16862: by the user writing to it but that may be changed externally, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16875: write to the file system, but once it does, it should not accept a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16918: understood that this may not always be possible since a user-level draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16919: copy may be thought of as creating a new data set and the tools used draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16920: may have no mechanism to propagate this data. When a file system is draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16928: The opaque string fss_current should provide whatever information is draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16932: server on which the change was made, etc. All information should be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16945: to the ultimate data source. Using this value, the client may be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16946: able to decide that a data copy is too old, so that it may search for draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16952: the server may provide such a value, but there is no guarantee as to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16963: successor images are accepted, it must make sure that it does not draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16979: In order to accept valid images reliably, the client must do a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16985: must be exercised to make sure that the data in question is not used draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16989: open file in question must not be accessed until that fs_status is draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16995: flight can be resolved by assembling them into the required partial draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16996: order (and the elements should form a total order within the partial draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:16997: order) and using the last. The client may then, when switching among draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17052: of this responsibility may be delegated to the client under strictly draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17107: within the namespace, owner, ACL, and other attributes. Metadata may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17115: file system information held at the server. Some servers may contain draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17118: servers may hold both metadata and a varying degree of file data. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17164: client and server and it may be possible that a client and server do draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17177: state required by the storage devices to perform client access draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17255: overlap each other, both layouts must be of the same layout type, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17279: A storage device may validate I/O with regard to the iomode; this is draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17282: performed, the storage device may reject the client's I/O with an draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17283: error indicating that a new layout with the correct iomode should be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17296: depend on writing into the same file concurrently may use byte-range draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17314: information may be required to fully address a storage device. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17344: server is not required to change the mappings.) A server has two draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17369: The server MUST support notifications and the client must request draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17452: client to access a storage device, a layout must be held by the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17464: device access permissions may be granted by LAYOUTGET and may be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17478: inaccessible to a client. Note, clients are still required to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17481: to circumvent these operations and the consequences of doing so must draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17483: In addition, these specifications must be clear about the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17505: range as described in Section 18.43.3. As needed a client may send draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17509: In order to get a layout, the client must first have opened the file draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17520: Therefore, a client may hold a layout for a file that is not draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17577: only the pNFS sections of this document should be considered to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17595: the client may determine the order of operation processing by draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17599: layout ranges may occur because of the client's specific requests or draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17606: use. The client must fully process the operations before the "seqid" draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17615: provide the order of processing. LAYOUTGET results may be processed draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17616: in parallel. LAYOUTRETURN results may be processed in parallel. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17617: LAYOUTGET and LAYOUTRETURN responses may be processed in parallel as draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17632: Related issues arise for storage protocols where a layout may hold draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17649: layout to the metadata server. The data should be written and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17657: global view that accounts for other clients' I/O that may have draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17660: For block/volume-based layouts, LAYOUTCOMMIT may require updating the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17664: size attribute, is required. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17680: The change and time_modify attributes may be updated by the server draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17687: value may or may not be used. The server should sanity-check the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17689: should ensure that time does not flow backwards. The client always draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17703: and time_modify attributes may be updated at the metadata server. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17706: required to update the change attribute. In this case, the metadata draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17707: server must ensure that no further update to the data has occurred draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17708: since the last update of the attributes; file-based protocols may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17709: have enough information to make this determination or may update the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17715: should be visible if that file was modified since the latest previous draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17720: The size of a file may be updated when the LAYOUTCOMMIT operation is draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17737: The metadata server may do one of the following: draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17742: value for file size should be sanity-checked. For example, the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17743: file must not be truncated if the client presents a last write draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17747: must have sufficient knowledge from other sources to determine draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17763: of file size, the metadata server must rely on the client to set the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17768: LAYOUTCOMMIT, the metadata server must reply with the new size; draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17772: complete. For example, the client should be able to read up to the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17818: may recall a layout identified by a byte-range, all layouts draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17824: iomode in the recall request must match the layout being returned; draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17825: for example, a recall with an iomode of LAYOUTIOMODE4_RW should cause draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17829: other words, the client must return both LAYOUTIOMODE4_READ and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17834: to reclaim state stored on the client. Since a REMOVE may be delayed draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17835: until the last close of the file has occurred, the recall may also be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17837: been released and the file has been removed, the client should no draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17849: clients, or their semantics, it recognizes that some clients may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17851: provided by pNFS. However, write-behind caching may negatively draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17859: has passed, the server may choose to fence the client's access to the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17870: and DELEGRETURN, the server may choose to wait, given that the client draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17891: CB_COMPOUND), the result may be significantly less client-server draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17894: o It may be useful for servers to maintain information about what draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17899: may request and be granted sub-file ranges. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17901: o It may be useful for clients to "forget" details about what draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17935: part of a single operation, but may be returned in portions. This draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17946: requests may be presented to a storage device no longer allowed to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17948: client will return the layout, the server may later decide to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17951: must deal with the possibility of lingering I/O requests, i.e., I/O draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17955: supported; if it is, the specification must also describe how draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17967: the client should return the NFS4ERR_NOMATCHING_LAYOUT error code to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:17994: concerns callbacks. The protocol must defend against races between draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18016: may race with the CB_LAYOUTRECALL. The client MUST wait for all the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18070: the LAYOUTGET must be waited for because it may be carrying draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18079: result, as the client must wait for the LAYOUTGET response before draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18159: may contain the same value for "seqid". The server uses a slightly draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18191: 1" is to allow for the required SEQUENCE operation. The server MAY draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18278: Asynchronous writes written through the metadata server may be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18283: While the write is pending, reads to the storage device may give out draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18328: uses the OPEN operation. With the normal set of attributes that may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18336: after the OPEN within the same COMPOUND. The GETATTR may then draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18339: file and therefore what storage protocol the client must use. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18352: wants to do I/O on. The response is a layout, which may be a subset draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18374: to send, these I/O requests may be done in parallel. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18376: If the I/O was a WRITE, then at some point the client may want to use draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18387: server introduces subtleties that must be handled correctly if the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18400: will expire and the server will know that state may be released. For draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18401: layouts, the server may release the state immediately upon lease draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18402: expiry or it may allow the layout to persist, awaiting possible lease draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18413: successful LAYOUTCOMMIT is in an undefined state; it may have been draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18414: written or it may now be lost. This is acceptable behavior and it is draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18457: may get an indication that the layout state was not moved with the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18465: While clients SHOULD NOT send I/Os to storage devices that may extend draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18547: layout because the contents of the response from LAYOUTGET may not draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18551: be the same, the device IDs may map to different device addresses, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18621: server's grace period. The metadata server may allow these draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18623: server must reliably determine that servicing such a request will not draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18625: the metadata server must reliably determine that servicing the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18635: implementation, the metadata server may be able to determine that a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18636: particular request is safe. For example, a metadata server may save draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18640: time of restart, and the metadata server may use this information draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18709: system (see Figure 1) is required to preserve the security properties draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18716: storage devices may take the form of physical isolation or a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18718: example, it may be impractical to provide confidentiality protection draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18724: fall back to conventional NFSv4.1) may be appropriate courses of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18755: should examine the layout specification, such as the NFSv4.1/file- draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18827: should set bits that represent the higher of the acceptable draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18841: the intended use by the client, the client should send the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18852: client may use the client ID to create sessions that will exchange draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18882: NFS client's data cache invalid. The client's cache should map a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18936: type and may be applicable to other layout types. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:18956: A pattern may have more stripe units than data servers. If so, some draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19021: preference for whether the client should send COMMIT operations to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19068: represents a data server address that may serve equally as the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19110: should send COMMIT operations to the metadata server or data draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19119: file where the striping pattern starts. It is required for draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19616: client to switch to another data server address which may be that of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19677: operations. The client may use these operations in order to set up draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19759: to the non-data-server personality. Stateids must obey the rules of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19761: non-zero seqid values must result in NFS4ERR_BAD_STATEID. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19789: new size must be visible on the metadata server once a LAYOUTCOMMIT draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19836: COMMIT implementation must return the same writeverf. The value draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19847: to a COMMIT to the MDS may differ than that of an offset used to a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19851: the client should compare it to all the verifiers from the WRITEs and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19853: the metadata server fails, the client should re-send WRITEs for all draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19854: the modified data in the file. The client should treat modified data draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19862: is FALSE, a COMMIT sent to the metadata server should be used only to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19870: it may be useful. For example, if the server implementation supports draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19874: the data. The client may default to an iomode of LAYOUTIOMODE4_RW. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19913: propagated, the existence of a valid stateid on the data server may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19927: delegation stateid should be used. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19929: o Otherwise, there must be an OPEN stateid for the current open- draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19942: use of the OPEN stateid, then the client should use the byte-range draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19946: o Special stateids should never be used. If they are used, the data draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19963: the propagation must be complete before returning to the client. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19972: though the details of the control protocol may avoid actual transfer draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:19979: privileges, these changes need not be propagated immediately, and may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20018: must be taken to ensure that the resultant state across the set of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20028: synchronization. It should be noted that by using an NFSv4.1-based draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20055: in ACLs may be asynchronous only if the server implementation is able draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20067: to the beginning of the file and reads byte 100. The client should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20071: data server servicing the READ may believe that the file's size is draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20135: given out by a previous instance, it must make sure that all layout draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20139: o The metadata server must not restripe a file until it has draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20143: o The metadata server must not give out mandatory locks that draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20152: make all of the required access checks on each READ or WRITE I/O as draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20197: representation must allow reasonable name/string access to clients draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20207: must define a profile of stringprep "in order to fully specify the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20223: each. Each profile defines the following, as required by stringprep: draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20252: reader should assume UTF-8. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20313: later revision of this specification may specify a particular draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20315: they may receive unnormalized characters within protocol requests and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20317: the implementation must normalize utf8str_cs strings within the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20526: Where the client sends an invalid UTF-8 string, the server should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20535: presence in the Unicode standard), the server should return draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20540: allow that particular name to be used, the server should return the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20709: may pre-parse all operations for a Compound procedure before doing draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20731: operation in what was deemed a reasonable time. The client should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20798: was returned, the requester should retry the request in full, with draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20809: To avoid this situation, the client should reissue the request draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20810: without the non-idempotent operation. The request still must use draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20852: specific legal NFSv4.1 protocol error values. The client should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20853: translate this into an appropriate error. UNIX clients may choose to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20908: used. It may have been made accessible on a different set of network draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20909: addresses, relocated or migrated to another server, or it may have draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20910: never been present. The client may obtain the new file system draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20916: non-idempotent operations may have been successfully executed within draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20919: the NFS4ERR_MOVED should not be re-executed in full. Instead, the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20920: client should send a new COMPOUND, with any successfully executed draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20922: session for the new COMPOUND, its SEQUENCE operation should use a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20927: The logical current or saved filehandle value is required by the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20928: current operation and is not set. This may be a result of a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20935: directory for an operation in which a directory is required. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:20974: There are a number of basic constraints on the operations that may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:21010: stream may be different. Where an illegal value appears and the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:21012: doing any operation execution, an RPC-level XDR error may be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:21081: specified to CREATE. This may be because the type is undefined, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:21104: is currently open. Servers may, but are not required to, disallow draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:21125: hard links a file may have to be exceeded. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:21149: inappropriately crosses a boundary. This may be due to such draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:21179: Depending on the operation, the stateid when valid may designate draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:21243: client should change the security mechanism being used and re-send draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:21311: An attempt to lock a file is denied. Since this may be a temporary draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:21405: In the case of a per-fs grace period, there may be clients, (i.e., draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:21487: Layouts are temporarily unavailable for the file. The client should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:21548: may have been retired. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:21638: clients. The client should recover by changing the co_ownerid and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:21793: error) is not listed but should be understood to be returnable by all draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:22689: error) is not listed but should be understood to be returnable by all draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24059: In the processing of the COMPOUND procedure, the server may find that draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24070: of attributes. In this case, the server may encounter an XDR decode draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24089: results array length is non-zero, this status must be equivalent to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24116: implementor. It may be used to summarize the content of the Compound draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24171: LOOKUP, the saved filehandle must be set directly with the use of the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24177: filehandle value may be used a sort of "scratch" area for the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24198: current filehandle. The current stateid may only be changed by an draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24340: The client is generally required to implement the operations needed draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24343: operation and is not required to do so. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24365: operation descriptions themselves must be consulted along with other draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24598: The following access permissions may be requested: draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24626: from the server. Strictly speaking, the server should not allow draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24635: implementation claiming conformance to UNIX may indicate in the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24779: attribute. This is because the server may perform uid or gid mapping draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24781: possible that the server may not be in the same ID space as the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24802: The client should use the effective credentials of the user to build draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24859: CLOSE, but some servers may not support the CLOSE of a file that draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24887: the client and should be treated as deprecated. CLOSE "shuts down" draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24896: A CLOSE operation may make delegations grantable where they were not draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24897: previously. Servers may choose to respond immediately if there are draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24898: pending delegation want requests or may respond to the situation at a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24956: by the COMMIT operation. The server must vary the value of the write draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24957: verifier at each server event or instantiation that may lead to a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24959: is restarted; however, other events at the server may result in draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24971: disk or stable storage for the specified file. Like fsync(), it may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24981: synchronize. The data may have been synchronized by the server's draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24982: normal periodic buffer synchronization activity. COMMIT should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24992: offset zero and count zero, it should do the equivalent of applying draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24993: fsync() to the entire file. Otherwise, it should arrange to have the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:24996: with the file must be flushed to stable storage before returning. It draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25009: a COMMIT is for a full file flush, such as may be done at close. In draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25018: the buffer must be considered as modified by the client until the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25038: interest, then it should be sent in a WRITE request with the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25067: void; /* server should return NFS4ERR_BADTYPE */ draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25113: The current filehandle must be a directory: an object of type NF4DIR. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25140: object. The set of attributes may include any writable attribute draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25158: the server's operating environment or file system semantics may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25241: The DELEGPURGE operation should be used by clients that record draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25244: should immediately send a DELEGPURGE operation. Doing so will notify draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25286: Delegations may be returned voluntarily (i.e., before the server has draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25287: recalled them) or when recalled. In either case, the client must draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25352: File systems that are absent should be treated as having support for draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25502: file and the target directory must reside within the same file system draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25505: with the same name as newname, the server must return NFS4ERR_EXIST. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25518: LINK may not be done when the file is open or when that open is done draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25528: accurate account of the opens for that client, since the client may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25529: execute OPENs and CLOSEs locally. The LINK operation must be delayed draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25541: NFS4ERR_FILE_OPEN may be returned to the caller as soon as that draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25570: attributes for the file should have a value for numlinks that is one draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25573: The statement "file and the target directory must reside within the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25576: file systems, the error NFS4ERR_XDEV is returned. This error may be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25599: attribute within that directory, the server may return the error draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25737: Bytes in a file may be locked even if those bytes are not currently draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25825: provided in the arguments should be returned in the denied results. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25829: specific right and modes required for various types of locks reflect draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25842: client may return an error, or it may emulate the required draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25851: may not perfectly reflect the required semantics in the face of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25857: clients. Therefore, the client may be handling locking requests draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25859: that, it must be prepared to update the lock status on the server, by draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25866: LOCK operation may not be granted until all such delegations are draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25948: in the arguments should be returned in the denied results. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25955: As noted in Section 18.10.4, some servers may return draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25961: for the current lock-owner, and thus should return NFS4_OK in such draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:25966: When a client holds an OPEN_DELEGATE_WRITE delegation, it may choose draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26012: parameters. The client may set the locktype field to any value that draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26048: actually held by the lock-owner, the server may return the error draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26054: receiving this error should, if it desires support for such draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26059: When a client holds an OPEN_DELEGATE_WRITE delegation, it may choose draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26107: up, it may construct a COMPOUND request such as (and obtain each draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26128: should provide a pseudo file system into which the exported file draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26135: these names. The LOOKUPP operator must be used to look up a parent draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26177: directory, an NFS4ERR_NOENT error must be returned. Therefore, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26188: (a future minor revision of NFSv4 may upgrade this to MUST) in the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26202: detached from the namespace, and this property should be safely draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26204: attribute directory may return the filehandle of the associated file, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26215: Therefore, the client may want to hide the parent of named attribute draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26250: operations may obtain new data associated with that object, for draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26563: the client must check to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26621: /* Client must confirm open */ draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26629: * Server may use CB_NOTIFY_LOCK on locks draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26686: UNCHECKED4 means that the file should be created if a file of that draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26690: may include any writable attribute valid for regular files. When an draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26707: creation of the target. The server should check for the presence of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26732: Unlike EXCLUSIVE4, attributes may be provided in the EXCLUSIVE4_1 draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26733: case, but because the server may use attributes of the target object draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26734: to store the verifier, the set of allowable attributes may be fewer draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26813: arguments. The client specifies at OPEN the required share_access draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26900: | | filehandles; the client may not have the | draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26945: For any OPEN request, the server may return an OPEN delegation, which draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26948: server to decide. The client should never assume that delegation draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26949: will or will not be granted in a particular instance. It should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26953: may specify an immediate recall in the delegation structure. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26974: o OPEN4_RESULT_MAY_NOTIFY_LOCK indicates that the server may attempt draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:26976: hint only, and may be safely ignored by the client. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27007: ACE, group, or group ACE if any of the four attributes are required draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27014: to create files for, then the server may return NFS4ERR_PERM. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27134: The client may set one or both of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27194: client, perhaps the RPC transaction identifier, may be appropriate. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27199: server may use one or more elements of the object's metadata to store draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27206: not survive a crash and the session and reply cache may be deleted draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27235: retentevt_set (it may be desired to establish retention at draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27245: size (on some servers, size may have a limited range of values), draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27251: time_creation (a meaningful file creation should be set when the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27268: it should fail the OPEN request with the error NFS4ERR_NOTSUPP. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27321: should check that the requester has the proper access rights to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27333: should not attempt to second-guess the server's decisions, as access draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27334: rights may change and may be subject to server administrative draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27426: because the server may maintain the state indefinitely as long as draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27477: attribute directory should be created as a result of the OPENATTR draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27478: operation. Some clients may use the OPENATTR operation with a value draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27488: and is not required to do so by this definition. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27542: situation, a close of one of the opens may change the appropriate draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27580: should be subsets of those already granted, short of a defect in the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27592: An OPEN_DOWNGRADE operation may make OPEN_DELEGATE_READ delegations draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27593: grantable where they were not previously. Servers may choose to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27595: may respond to the situation at a later time. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27673: This filehandle may be different from the "root" filehandle that may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27699: whether the pathname provided in the LOOKUP should be evaluated as draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27711: to the use of absolute evaluation and the restrictions the server may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27715: an NFSv3 absolute public filehandle look up may behave differently draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27729: framework as NFSv3. Clients should therefore use the security draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27754: server. This filehandle may be different from the "public" draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27755: filehandle that may be associated with some other directory on the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27822: checking. The server may choose to return fewer bytes than specified draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27865: and eof is set to FALSE), the client should send another READ to get draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27866: the remaining data. A server may return less data than requested draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27867: under several circumstances. The file may have been truncated by draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27872: short read result. Server resource exhaustion may also occur in a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27878: server will return the NFS4ERR_LOCKED error. The client should try draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27880: attempting the READ. When the READ completes, the client should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27884: being read, the delegation must be recalled, and the operation cannot draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27900: client should have done an OPEN previously. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27984: READDIR should start within the directory. A value of zero for the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27989: The request's cookieverf field should be set to 0 zero) when the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27991: subsequent requests, the cookieverf field must match the cookieverf draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:27994: directory, the error NFS4ERR_NOT_SAME must be returned. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28006: bytes of directory information that should be returned. This value draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28031: the client for subsequent READDIR operations so that it may continue draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28035: the client may be caching these values. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28037: In some cases, the server may encounter an error while obtaining the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28043: Obviously, the client must request the fattr4_rdattr_error attribute draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28075: greatly. A client's programming interfaces may also be bound to the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28086: The cookieverf may be used by the server to help manage cookie values draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28087: that may become stale. It should be a rare occurrence that a server draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28105: requires these entries be present in READDIR responses must fabricate draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28157: symbolic links, then they must agree on the interpretation of the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28161: The server should return the error NFS4ERR_WRONG_TYPE if the object draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28202: corresponding file system object, the object may be destroyed. The draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28203: directory may be either of type NF4DIR or NF4ATTRDIR. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28231: NFSv3 required a different operator RMDIR for directory removal and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28239: and rmdir() system calls should first check the file type against the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28247: 1, the client should not rely on referring to the object via a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28248: filehandle. Likewise, the client should not rely on the resources draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28252: the client should take steps to make sure that the file will still be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28373: the current filehandle. The operation is required to be atomic to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28425: RENAME may not be done when the file being renamed is open or when draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28427: or access modes. Similar restrictions may be applied when a file draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28442: accurate account of the opens for that client, since the client may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28455: semantics, NFS4ERR_FILE_OPEN may be returned to the caller as soon as draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28516: The RENAME operation must be atomic to the client. The statement draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28523: the filehandle may or may not expire on a RENAME. However, server draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28715: name pair. SECINFO should apply the same access methodology used for draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28848: NOTE: In NFSv4.0, the client was required to use SECINFO, and had draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28919: object matches the value specified in the request. Some servers may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28923: implementation may be simplified in cases of creation of an object draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28933: Clients should not make any assumptions regarding a server's draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28938: SETATTR is not guaranteed to be atomic. A failed SETATTR may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28944: SETATTR, the delegation(s) must be recalled, and the operation cannot draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28979: time_modify and change attributes. A client must account for this as draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28991: to file times can break. A time synchronization protocol should be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:28996: whereby a client may specify a request that emulates the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29043: the error NFS4ERR_NOT_SAME must be returned. The current filehandle draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29129: specifies the offset where the data should be written. An offset of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29130: zero specifies that the write should start at the beginning of the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29165: server may write fewer bytes than requested. If so, the actual draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29265: uncommitted data may be lost. In the most likely case, the verifier draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29267: required so that the client can safely determine whether the server draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29283: server that uses an NVRAM accelerator may choose to implement this draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29296: Some implementations may return NFS4ERR_NOSPC instead of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29339: though the client should have done an OPEN previously. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29500: state protection, the client is not required to use draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29561: codes use a subkey derived from the SSV as the key and the SSV may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29591: o The attempted BIND_CONN_TO_SESSION with the old SSV should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29727: Migration), the client may still use EXCHANGE_ID to obtain the client draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29746: occurred previously, the client ID must first be used, along with the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29754: operations may be needed for other reasons. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29797: clients to determine when client IDs sent by one server may be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29835: These properties may be updated by subsequent EXCHANGE_ID draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29897: recommended that the key used as input to an HMAC be at draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29913: the subkey derivation is via an HMAC and it is recommended draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29914: that if the HMAC has to be truncated, it should not be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29921: property may be updated by subsequent EXCHANGE_ID operations. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29924: eia_client_impl_id field of the arguments. The property may be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29928: eir_server_impl_id field of the reply. The property may be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29986: a server may use the fact that the client is incapable of correctly draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29988: It may, for instance, act as a proxy for that particular file system, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:29997: when this in fact happens. However, a server may use the fact that draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:30000: file systems being actively used. It may also hide actual migrations draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:30041: different client IDs, the client may ask for different properties for draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:30103: indicates that CREATE_SESSION must be protected with SP4_SSV, because draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:30218: This is the number of RPCSEC_GSS handles the server should create draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:30286: identifier but are required to interoperate as specified elsewhere in draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:30395: Since EXCHANGE_ID is a non-idempotent operation, we must consider the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:30446: Since the record has been confirmed, the client must have draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:30492: returns NFS4ERR_CLID_INUSE to indicate that the client should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:30538: should be released immediately rather than forcing the new draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:30540: incarnation to expire. Furthermore, session state should be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:30544: CLAIM_DELEG_PREV_FH claim types, associated delegations should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:30590: Since the record has been confirmed, the client must have draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:30890: requests with a READ operation) should not be cached. The draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31030: consider the possibility that retries may occur as a result of a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31289: that retries the request may receive an error in reply to the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31340: delegations, and layouts). This may be because of client LOCKU draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31459: or more bits in a bitmap. The server may refuse to grant the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31498: indicated on return. If so, the client should expect a future draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31521: synchronous callbacks. A server must support synchronous callbacks draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31551: client asks for may depend on the directory size, its rate of change, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31577: support or that may cause significant resource consumption on the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31579: server should not commit to sending out notifications for attributes draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31580: and therefore must not set the appropriate bit in the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31654: server may return less data. If the server is unable to return any draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31667: receiving; the server must support device ID notifications for the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31726: client should send a TEST_STATEID request using the stateid for draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31728: indicates that any layouts have been revoked, the client must draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31731: revoked, the client should send a GETDEVICEINFO operation on the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31743: no harm is done. The client should mark the device ID as deleted, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31746: ID should be removed from the client's cache. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31758: mappings have changed. The client should assume that the results draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31760: once received, and so it should send another GETDEVICEINFO on the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31834: it may be helpful for a client to determine device accessibility upon draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31936: segment is not LAYOUTIOMODE4_RW, the server should return the error draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31939: should return the error NFS4ERR_BAD_LAYOUT. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31943: may have only written a subset of the data range it previously draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31953: period (see Section 12.7.4). This type of request may be necessary draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31969: must send a LAYOUTGET request to the server after the server's grace draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31984: Setting the loca_reclaim field to TRUE is required if and only if the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:31998: described by loca_offset and loca_length. The metadata server may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32001: result of the LAYOUTCOMMIT operation, it must return the new size draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32006: metadata server may use the suggestion or it may use the time of the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32008: server uses the client-provided modification time, it should ensure draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32010: metadata server to set an exact time, the client should use a SETATTR draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32013: time, it should construct the COMPOUND so that a GETATTR follows the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32041: NFS4ERR_BADLAYOUT is returned. The layout being committed may also draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32054: may help the metadata server to recover files more efficiently after draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32055: restart. For example, some file system implementations may require draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32059: their writes. Sending a LAYOUTCOMMIT (if required) and then draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32119: depends upon the layout type, but should reflect the client's data draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32132: loga_minlength - 1 inclusive. This range indicates the required draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32324: will contain the required number of entries. The elements of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32332: logr_layout array, more description is required. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32397: For the metadata server that knows a layout must be returned before a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32450: should expect a CB_RECALLABLE_OBJ_AVAIL operation to indicate that a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32462: stateid, which is set by OPEN (see Section 16.2.3.1.2). A client may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32754: The layout being returned may be a subset or superset of a layout draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32767: LAYOUTRETURN4_ALL. There must be a LAYOUTRETURN with a matching draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32800: Layouts may be returned when recalled or voluntarily (i.e., before draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32801: the server has recalled them). In either case, the client must draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32808: LAYOUTRECALL4_FILE, the client should use the lor_stateid value from draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32809: CB_LAYOUTRECALL as the value for lrf_stateid. Otherwise, it should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32825: the client should not be using the old seqid. For example, the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32848: operations for which a LAYOUTRETURN operation must be done, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32883: may recall a superset of that range (e.g., LAYOUTRECALL4_ALL); the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32884: final return operation for the latter must block until the former draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32935: passed, then SECINFO_NO_NAME is querying for the required security draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32937: SECINFO_NO_NAME is querying for the required security of the current draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32939: then SECINFO should apply the same access methodology used for draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:32942: LOOKUPP the parent, then SECINFO_NO_NAME must behave the same way and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:33104: SEQ4_STATUS_CB_PATH_DOWN_SESSION may be set and not draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:33181: client's failure to return them when recalled, which may be a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:33199: When set, indicates that due to server restart, the client must draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:33293: partially executed COMPOUND, processing may reach an operation not draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:33454: stateids. It can be used at any time, but the client should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:33693: aforementioned file types, the server must set draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:33699: trigger the recall of the existing delegation. Servers may choose to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:33750: preceding it, a client that retransmits the request may receive an draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:33820: current filehandle is required when rca_one_fs is set to TRUE. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:33853: It should be noted that there are situations in which a client needs draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:33861: These two may be done in any order as long as all necessary lock draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:33876: should be aware that such operations may temporarily result in draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:33900: When there are no reclaims to be done, RECLAIM_COMPLETE should be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:33904: RECLAIM_COMPLETE should only be done once for each server instance or draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:33921: RECLAIM_COMPLETE with rca_one_fs set to TRUE when it should have not draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34228: During the processing of the CB_COMPOUND procedure, the client may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34348: only for the change attribute, and attributes that it may change draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34469: following fields must match those of the layout: clora_type, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34471: and lor_length. The clora_iomode field may have a special value draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34517: indicates that no change in the layout is expected and the client may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34518: write modified data to the storage devices involved; this must be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34546: client should wait for the response from in-process or in-flight draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34559: server. As always, the client may write the data through the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34560: metadata server. In fact, the client may not have a choice other draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34563: the client may be able to write the modified data to the storage draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34568: that before obtaining a new layout, the client must first return the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34572: the client must use LAYOUTCOMMIT operations at the appropriate time; draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34573: as required LAYOUTCOMMIT must be done before the LAYOUTRETURN. If a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34574: large amount of modified data is outstanding, the client may send draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34740: caches and directory caches where this entry should be cached. If draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34849: NFS4ERR_REJECT_DELAY, the want remains pending, although servers may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34881: The server may decide that it cannot hold all of the state for draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34906: the server's knowledge of available resources must be used to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34907: determine when objects must be recalled with the clients selecting draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34910: Server implementations may differ in their resource allocation draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34911: requirements. For example, one server may share resources among all draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34912: classes of recallable objects, whereas another may use separate draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34921: usefulness, which of the objects in that class should be returned. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34928: bits within its range are to be used. For example, it may specify a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34930: area) and the bit to be used, or it may define a field in the layout draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34977: be returned. Future minor versions of NFSv4 may expand the set of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34980: CB_RECALL_ANY specifies a count of objects that the client may keep draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34981: as opposed to a count that the client must return. This is to avoid draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:34988: If resource demands prompt it, the server may send another draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35008: that this means that a server may not cancel the effect of a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35029: type, it should only specify that type in the mask it sends. Should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35033: usage. The server should give the client enough time to return draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35034: objects before proceeding to specific recalls. This time should not draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35345: may need to make clear to the client whether a promise to signal draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35378: client that has been polling for a blocking byte-range lock may now draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35382: commit the server to the use of CB_NOTIFY_LOCK, but the client may draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35412: The server is not required to implement this callback, and even if it draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35413: does, it is not required to use it in any particular case. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35414: Therefore, the client must still rely on polling for blocking locks, draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35417: Similarly, the client is not required to implement this callback, and draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35490: registration of device ID notifications is optional and is done via draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35690: of this possibility, the following considerations should be taken draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35798: while undesirable and a potential security exposure, may not be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35883: IANA should reject any assignment request with a named attribute that draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35891: conflicting with an assignment in IANA's registry should use the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35905: must not allow two assignments that would conflict if both named draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35912: This name must be unique. This string name can be 1 to 128 UTF-8 draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35944: basis per Section 4.1 of [62], with Expert Review required. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35957: 1. The name of the notification type. This name must have the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35958: prefix "NOTIFY_DEVICEID4_". This name must be unique. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35963: than 2^32-1, and should be the next available value. The value draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35964: assigned must be unique. A Designated Expert must be used to draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35984: minor version of NFSv4 approved, a Designated Expert should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:35985: review the registry to make recommended updates as needed. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36032: per Section 4.1 of [62], with Expert Review required. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36041: 1. The name of the recallable object type. This name must have the draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36042: prefix "RCA4_TYPE_MASK_". The name must be unique. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36047: higher than 2^32-1, and should be the next available value. The draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36048: value must be unique. A Designated Expert must be used to ensure draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36077: should review the registry to make recommended updates as needed. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36116: with Expert Review required. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36132: 1. The name of the layout type. This name must have the prefix draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36133: "LAYOUT4_". The name must be unique. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36137: actual value. The value assigned must be unique. A Designated draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36138: Expert must be used to ensure that when the name of the layout draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36146: Collectively, the RFC(s) must adhere to the guidelines listed in draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36159: minor version of NFSv4 approved, a Designated Expert should draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36160: review the registry to make recommended updates as needed. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36198: The author of a new pNFS layout specification must follow these steps draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36305: "ietf.org", all variables names must be registered with IANA on a draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36306: Standards Action basis, with Expert Review required. Path variables draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36321: 1. The name of the variable. The name of this variable must start draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36323: ":", or it must start with "${FCFS.ietf.org". The name must be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36324: no more than 64 UTF-8 characters long. The name must be unique. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36393: 1. A value of the ${ietf.org:CPU_ARCH} variable. The value must be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36394: 1 to 32 UTF-8 characters long. The value must be unique. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36432: 1. A value of the ${ietf.org:OS_TYPE} variable. The value must be 1 draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:36433: to 32 UTF-8 characters long. The value must be unique. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:37231: is already aware of a given client instance must be either draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:37284: implementations that may have arisen due to the lack of clarity of draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:37289: The new handling of various situations required revisions of some draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:37398: creates needs to be addressed. Addressing this issue must not be draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:37400: OPTIONAL was justified and whether it should be changed. draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:37402: In any event, it may not be possible, at this point, to correct draft-ietf-nfsv4-rfc5661sesqui-msns-04.txt:37458: zero as well, it may make sense to deal with these security issues in