idnits 2.17.1 draft-ietf-nfsv4-requirements-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1998) is 9325 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2025' on line 567 looks like a reference -- Missing reference section? 'RFC1094' on line 537 looks like a reference -- Missing reference section? 'RFC1813' on line 543 looks like a reference -- Missing reference section? 'RFC1831' on line 549 looks like a reference -- Missing reference section? 'RFC1832' on line 555 looks like a reference -- Missing reference section? 'RFC1833' on line 561 looks like a reference -- Missing reference section? 'RFC2078' on line 573 looks like a reference -- Missing reference section? 'RFC2203' on line 581 looks like a reference -- Missing reference section? 'Sandberg' on line 587 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Spencer Shepler 2 Internet Draft October 1998 3 Document: draft-ietf-nfsv4-requirements-02.txt 5 NFS Version 4 Requirements 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet- Drafts as reference 17 material or to cite them other than as "work in progress." 19 To view the entire list of current Internet-Drafts, please check the 20 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 21 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 22 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 23 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 25 Abstract 27 With the creation of the NFS version 4 working group, a set of 28 requirements for the next version of NFS must be codified to create a 29 reasonable context for the new protocol discussions and aide in the 30 upcoming decisions. This Internet Draft has the purpose of 31 presenting the requirements for NFS version 4 and will be used as the 32 leading document for NFSv4 working group. 34 NFSv4 NFSv4 Requirements October 1998 36 Table of Contents 38 1. NFS Version 4 Requirements . . . . . . . . . . . . . . . . . 3 39 2. Ease of implementation or complexity of protocol . . . . . . 3 40 2.1. Extensibility / layering . . . . . . . . . . . . . . . . . 3 41 2.2. Managed Extensions or Minor Versioning . . . . . . . . . . 3 42 3. Reliable and Available . . . . . . . . . . . . . . . . . . . 4 43 4. Scalable Performance . . . . . . . . . . . . . . . . . . . . 4 44 4.1. Throughput and Latency on the Network . . . . . . . . . . 5 45 4.2. Server Work Load or Scalability . . . . . . . . . . . . . 5 46 4.3. Client Caching . . . . . . . . . . . . . . . . . . . . . . 5 47 4.4. Disconnected Client Operation . . . . . . . . . . . . . . 6 48 5. Interoperability . . . . . . . . . . . . . . . . . . . . . . 6 49 5.1. Platform Specific Behavior . . . . . . . . . . . . . . . . 6 50 5.2. Additional or Extended Attributes . . . . . . . . . . . . 6 51 5.3. Access Control Lists . . . . . . . . . . . . . . . . . . . 7 52 6. RPC Mechanism and Security . . . . . . . . . . . . . . . . . 8 53 6.1. Remote Procedure Call Mechanism . . . . . . . . . . . . . 8 54 6.2. User identification . . . . . . . . . . . . . . . . . . . 8 55 6.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 6.3.1. Authentication . . . . . . . . . . . . . . . . . . . . . 9 57 6.3.2. Data Integrity . . . . . . . . . . . . . . . . . . . . 10 58 6.3.3. Data Privacy . . . . . . . . . . . . . . . . . . . . . 10 59 6.3.4. Security Mechanisms . . . . . . . . . . . . . . . . . 10 60 6.3.5. Security Negotiation . . . . . . . . . . . . . . . . . 10 61 7. Internet Accessibility . . . . . . . . . . . . . . . . . . 10 62 7.1. Congestion Control and Transport Selection . . . . . . . 11 63 7.2. Firewalls and Proxy Servers . . . . . . . . . . . . . . 11 64 7.3. Multiple RPCs and Latency . . . . . . . . . . . . . . . 11 65 8. File locking / recovery . . . . . . . . . . . . . . . . . 12 66 9. Internationalization . . . . . . . . . . . . . . . . . . . 13 67 10. Bibliography . . . . . . . . . . . . . . . . . . . . . . 14 68 11. Author's Address . . . . . . . . . . . . . . . . . . . . 16 70 NFSv4 NFSv4 Requirements October 1998 72 1. NFS Version 4 Requirements 74 As stated in the charter the first deliverable for the NFS version 4 75 working group is this requirements document. This document is to 76 cover the "limitations and deficiencies of NFS version 3". Therefore 77 the intent of the following sections is to identify the various 78 feature points of NFS as a distributed file system and discuss its 79 current functionality and compare to other distributed file systems 80 and offer reasonable requirements for each of these areas. 82 2. Ease of implementation or complexity of protocol 84 One of the strengths of NFS has been the ability to implement a 85 client or server with relative ease. The eventual size of a basic 86 implementation is relatively small. The main reason for keeping NFS 87 as simple as possible is that a simple protocol design can be 88 described in a simple specification that promotes straightforward, 89 interoperable implementations. All protocols can run into problems 90 when deployed on real networks, but simple protocols yield problems 91 that are easier to diagnose and correct. 93 2.1. Extensibility / layering 95 With NFS' relative simplicity, the addition or layering of 96 functionality has been easy to accomplish. The addition of features 97 like the client automount or autofs, client side disk caching and 98 high availability servers are examples. This type of extensibility 99 is desirable in an environment where problem solutions do not require 100 protocol revision. This extensibility can also be helpful in the 101 future where unforeseen problems or opportunities can be solved by 102 layering functionality on an existing set of tools or protocol. 104 2.2. Managed Extensions or Minor Versioning 106 For those cases where the NFS protocol is deficient or where a minor 107 modification is the best solution for a problem, a minor version or a 108 managed extension could be helpful. There have been instances with 109 NFS version 2 and 3 where small straightforward functional additions 110 would have increased the overall value of the protocol immensely. 111 However, the perceived size and burden of using a change of RPC 112 version number for the introduction of new functionality led to no or 113 slow change. It is possible that a new NFS protocol could allow for 114 the rare instance where protocol extension within the RPC version 116 NFSv4 NFSv4 Requirements October 1998 118 number is the most prudent course and an RPC revision would be 119 unnecessary or impractical. 121 The areas of an NFS protocol which are most obviously volatile are 122 new orthogonal procedures, new well-defined file or directory 123 attributes and potentially new file types. It is possible and highly 124 desirable that these types of additions can be done without changing 125 the overall design model of NFS without significant effort or delay. 126 This is particularly true in adding new procedures. 128 A strong consideration should be given to a NFS protocol mechanism 129 for the introduction of this type of new functionality. This is 130 obviously in contrast to using the standard RPC version mechanism to 131 provide minor changes. The process of using RPC version numbers to 132 introduce new functionality brings with it a lot of history which may 133 not technically prevent its use. However, the historical issues 134 involved will need to be addressed as part of the NFS protocol work 135 to increase the chance of current and future success of the protocol. 137 3. Reliable and Available 139 Current NFS protocol design has lead to quick recovery from server 140 and client failure. This approach to the design has lent itself well 141 to layered technologies like high availability and clustered servers. 142 Providing a protocol design approach that lends itself to these types 143 of reliability and availability features is very desirable. 145 For the next version of NFS, consideration should be given to client 146 side availability schemes such as client switching between or fail- 147 over to available server replicas. If possible, the protocol should 148 allow for or ease the building of such layered solutions. 150 4. Scalable Performance 152 In designing and developing an NFS protocol from a performance 153 viewpoint there are several different points to consider. Each can 154 play a significant role in perceived and real performance from the 155 user's perspective. The three main areas of interest are: throughput 156 and latency on the network, server work load or scalability and 157 client side caching. 159 NFSv4 NFSv4 Requirements October 1998 161 4.1. Throughput and Latency on the Network 163 NFS currently has characteristics that provide good throughput for 164 the reading and writing of file data. However, the number of RPCs 165 required to accomplish some tasks combined with high latency network 166 environments leads to sluggish response. The protocol should 167 continue to provide good raw read and write throughput while 168 addressing the issue of network latency. This issue is discussed 169 further in the section on Internet Accessibility. 171 4.2. Server Work Load or Scalability 173 Current NFS operations are relatively lightweight in that the 174 processing work for most of the operations is not CPU intensive. 175 This allows for potential support of a large number of clients. This 176 attribute can also be helpful in building efficient and scalable SMP 177 or cluster based servers. While this type of protocol design 178 (lightweight operations) is desirable, it needs to be balanced 179 against the previous issue of having the client generate a large 180 number of RPCs to accomplish a straight forward task. 182 4.3. Client Caching 184 In an attempt to speed response time and to reduce network and server 185 load, NFS clients have always cached directory and file data. 186 However, this has usually been done as memory cache and in relatively 187 recent history, local disk caching has been added. 189 Having the client cache directory and file data is very desirable. 190 Other distributed file systems have shown that aggressive client side 191 caching can be very visible to the end user in response time gains. 192 Client caching is increasingly important for Internet environments 193 where throughput can be limited and response time can grow 194 significantly. 196 The NFS protocol should allow for aggressive caching while balancing 197 the needs for simplicity and Internet accessibility (i.e. firewalls). 198 If possible, the caching ability should be layered on the protocol 199 instead of embedding specific client caching functions in the 200 protocol itself. 202 NFSv4 NFSv4 Requirements October 1998 204 4.4. Disconnected Client Operation 206 An extension of client caching is the idea or functionality of 207 disconnected operation at the client. With the ability to cache 208 directory and file data aggressively, a client could then provide 209 service to the end user while disconnected from the server or 210 network. 212 While very desirable, disconnected operation has the opportunity to 213 inflict itself upon the NFS protocol in an undesirable way as 214 compared to traditional client caching. Given the complexities of 215 disconnected client operation and subsequent resolution of client 216 data modification through various playback or data selection 217 mechanisms, disconnected operation should not be a requirement for 218 the NFS effort. Even so, the NFS protocol should consider the 219 potential layering of disconnected operation solutions on top of the 220 NFS protocol (as with other server and client solutions). The 221 experiences with Coda, disconnected AFS and others should be helpful 222 in this area. 224 5. Interoperability 226 The NFS protocols are available for many different operating 227 environments. Even though this shows the protocol's ability to 228 provide distributed file system service for more than a single 229 operating system, the design of NFS is certainly Unix centric. The 230 next NFS protocol needs to be more inclusively of platform or file 231 system features beyond those of traditional Unix. 233 5.1. Platform Specific Behavior 235 Because of its Unix centric design, some of the protocol requirements 236 have been difficult to implement in some environments. For example, 237 persistent file handles (unique identifiers of file system objects), 238 Unix uid/gid mappings, directory modification time, accurate file 239 sizes, file/directory locking semantics (SHAREs, PC-style locking). 241 5.2. Additional or Extended Attributes 243 NFS Versions 2 and 3 do not provide for file or directory attributes 244 beyond those that are found in the traditional Unix environment; for 245 example the user identifier/owner of the file, a permission or access 246 bitmap, time stamps for modification of the file or directory and 248 NFSv4 NFSv4 Requirements October 1998 250 file size to name a few. While the current set of attributes has 251 usually been sufficient, the file system's ability to manage 252 additional information associated with a file or directory can be 253 useful. 255 There are many possibilities for additional attributes in the next 256 version of NFS. Some of these include: object creation timestamp, 257 user identifier of file's creator, timestamp of last backup or 258 archival bit, version number, file content type (MIME type), 259 existence of data management involvement (i.e. DMAPI). 261 This list is representative of the possibilities and are meant to 262 show the need for an additional attribute set. Enumerating the 263 'correct' set of attributes is difficult and is one of the reasons 264 for looking towards minor versioning as a way to provide needed 265 extensibility. Another way to provide some extensibility is in 266 providing support for a generalized named attribute mechanism. This 267 mechanism would allow a client to name, store and retrieve arbitrary 268 data and have it associated as an attribute of a file or directory. 269 This type of extended attribute mechanism brings with it a large set 270 of issues that will need to be addressed in the protocol 271 specification while keeping the overall goal of simplicity in mind. 273 There are operating environments that provide named or extended 274 attribute mechanisms. Digital Unix provides for the storage of 275 extended attributes with some generalized format. HPFS and NTFS also 276 provide for named data associated with traditional files. SGI's 277 local file system, XFS, also provides for this type of name/value 278 extended attributes. However, there does not seem to be a clear 279 direction that can be taken from these or other environments. 281 5.3. Access Control Lists 283 Access Control Lists (ACL) can be viewed as one specific type of 284 extended attribute. This attribute is a designation of user access 285 to a file or directory. Many vendors have created ancillary 286 protocols to NFS to extend the server's ACL mechanism across the 287 network. Generally this has been done for homogeneous operating 288 environments. Even though the server still interprets the ACL and has 289 final control over access to a file system object, the client is able 290 to manipulate the ACL via these additional protocols. 292 Other distributed file systems have also provided ACL support. DFS, 293 AFS and CIFS to name a few. Based on current capabilities, it seems 294 to be a requirement that NFS provide this capability as well but the 295 major issue is one of compatibility. It may be problematic to create 296 a workable ACL mechanism that will encompass a reasonable set of 298 NFSv4 NFSv4 Requirements October 1998 300 functionality for all operating environments. 302 The three major reasons behind providing ACL support are existing 303 distributed file system support, file servers not providing native 304 environment for user management of ACLs and perception of ACL support 305 as part of security requirement. Even with the complicated nature of 306 ACL support it is still worthwhile to work towards a solution that 307 can at least provide basic functionality for the user. 309 6. RPC Mechanism and Security 311 NFS relies on the underlying security mechanisms provided by the 312 ONCRPC protocol. Until the introduction of the ONCRPC RPCSEC_GSS 313 security flavor, NFS security was generally limited to none 314 (AUTH_SYS) or DES (AUTH_DH). The AUTH_DH security flavor was not 315 successful in providing readily available security for NFS because of 316 a lack of implementation and deployment. Also the 192 bit public 317 keys modulos used for the AUTH_DH security flavor quickly became too 318 small for reasonable security. 320 6.1. Remote Procedure Call Mechanism 322 The ONCRPC protocol provides the basic NFS foundation for the 323 following reasons: 325 o Open protocol definition managed by IETF 327 o Transport independent (i.e. UDP and TCP supported) 329 o Simple data representation and procedure encoding models 331 o Various security mechanisms available through use of RPCSEC_GSS 333 6.2. User identification 335 NFS has been limited to the use of the Unix centric user 336 identification mechanism of numeric user id based on the available 337 file system attributes and the use of the ONCRPC. However, for NFS 338 to move beyond the limits of large work groups, user identification 339 should be string based and the definition of the user identifier 340 should allow for integration into an external naming service or 341 services. 343 NFSv4 NFSv4 Requirements October 1998 345 Internet scaling should also be considered for this as well. The 346 identification mechanism should take into account multiple naming 347 domains and other extremes that can be presented by use outside of 348 the work group. 350 If NFS is to move among various naming and security services, it may 351 be necessary to stay with a string based identification. This would 352 allow for servers and clients to translate between the external 353 string representation to a local or internal numeric (or other 354 identifier) which matches internal implementation needs. 356 DFS uses a string based naming scheme but translates the name to a 357 UUID (16 byte identifier) that is used for internal protocol 358 representations. The DCE/DFS string name is a combination of cell 359 (administrative domain) and user name. As mentioned, NFS clients and 360 servers map a Unix user name to a 32 bit user identifier that is then 361 used for ONCRPC and NFS protocol fields requiring the user 362 identifier. 364 6.3. Security 366 As a result of a lack of implementation and deployment and relatively 367 weak protection, authentication has been a major issue for ONCRPC and 368 hence NFS. With the introduction of the RPCSEC_GSS security flavor, 369 ONCRPC can provide for reasonable authentication along with integrity 370 and privacy, if desired. The RPCSEC_GSS framework will allow the use 371 of both public and private key mechanisms. Therefore, NFS as a user 372 of ONCRPC should state its specific requirements for each of these 373 areas. 375 In comparison, AFS and DFS provide strong authentication mechanisms. 376 CIFS does provide authentication at initial server contact but does 377 not continue this authentication during subsequent interaction. 379 6.3.1. Authentication 381 Strong authentication is a requirement for NFS and the logical 382 solution for this is in the use of ONCRPC and RPCSEC_GSS. This 383 solution will allow for both private and public key mechanisms to be 384 employed if required. This flexibility will allow for security 385 usability in varying environments. 387 NFSv4 NFSv4 Requirements October 1998 389 6.3.2. Data Integrity 391 Since file and directory data is the essence of distributed file 392 service, the NFS protocol should provide to the users of the file 393 service a reasonable level of data integrity. The RPCSEC_GSS 394 mechanism provides a framework for data integrity and the security 395 mechanisms chosen for NFS should be implemented to provide data 396 integrity. 398 6.3.3. Data Privacy 400 Data privacy, while desirable, is not as important in all 401 environments as authentication and integrity. Data privacy should be 402 an available option within NFS but not a requirement. 404 6.3.4. Security Mechanisms 406 With the use of the RPCSEC_GSS framework, both public and private 407 mechanisms can and should be provided by NFS. The choice from both 408 public and private key mechanisms will allow for the appropriate 409 choice being made by the user based on factors within their 410 environment. 412 Potential choices for the private key mechanism would be Kerberos V5 413 and for the public key choice, SPKM [RFC2025] is available. 415 6.3.5. Security Negotiation 417 With both private and public key mechanisms available to the end 418 user, the NFS server and client will need a method to negotiate 419 appropriate usage based on availability and policy. This negotiation 420 should account for authentication, integrity, and privacy so that 421 administrators and users can employ the appropriate security policies 422 for their environments. 424 7. Internet Accessibility 426 Being a product of an IETF working group, the NFS protocol should not 427 only be built upon IETF technologies where possible but should also 429 NFSv4 NFSv4 Requirements October 1998 431 work well within the broader Internet environment. 433 7.1. Congestion Control and Transport Selection 435 As with any network protocol, congestion control is a major issue and 436 the transport mechanisms that are chosen for NFS should take this 437 into account. Traditionally implementations of NFS have been 438 deployed using both UDP and TCP. With the use of UDP, most 439 implementations provide a rudimentary attempt of congestion control 440 with simple back-off algorithms and round trip timers. While this 441 may be sufficient in today's NFS deployments, as an Internet protocol 442 NFS will need to ensure sufficient congestion control or management. 444 With congestion control in mind, NFS must use TCP as a transport (via 445 ONCRPC). The UDP transport provides its own advantages in certain 446 circumstances. In today's NFS implementations, UDP has been shown to 447 produce greater throughput as compared to similarly configured 448 systems that use TCP. If UDP is to be supplied as an NFS transport 449 mechanism, then the issues of congestion control must be dealt with. 451 7.2. Firewalls and Proxy Servers 453 NFS's protocol design should allow its use via Internet firewalls. 454 The protocol should also allow for the use of file system proxy/cache 455 servers. Proxy servers can be very useful for scalability and other 456 reasons. The NFS protocol needs to address the need of proxy servers 457 in a way that will deal with the issues of security, access control, 458 and content control. It is possible that these issues can be 459 addressed by documenting the related issues of proxy server usage. 460 However, it is likely that the NFS protocol will need to support 461 proxy servers directly through the NFS protocol. In any case, the 462 NFS proxy server should be considered during protocol development. 464 7.3. Multiple RPCs and Latency 466 As an application at the NFS client performs simple file system 467 operations, multiple NFS operations or RPCs may be executed to 468 accomplish the work for the application. While the NFS version 3 469 protocol addressed some of this by returning file and directory 470 attributes for most procedures hence reducing follow up GETATTR 471 requests, there is still room for improvement. Reducing the number 472 of RPCs can lead to a reduction of processing overhead on the server 473 (transport and security processing) along with reducing the time 475 NFSv4 NFSv4 Requirements October 1998 477 spent at the client waiting for the server's individual responses. 478 This issue is more prominent in environments with larger degrees of 479 latency. 481 The CIFS file access protocol supports 'batched requests' that allow 482 multiple requests to be batched and therefore reducing the number of 483 round trip messages between client and server. 485 This same approach can be used by NFS to allow the grouping of 486 multiple procedure calls together in a traditional RPC request. Not 487 only would this allow for the reduction in protocol imposed latency 488 but would reduce transport and security processing overhead and could 489 allow a client to complete more complex tasks by combining 490 procedures. 492 8. File locking / recovery 494 NFS has provided Unix file locking and DOS SHARE capability with the 495 use of an ancillary protocol (Network Lock Manager / NLM). The NLM 496 protocol provides for file locking and recovery of those locks in the 497 event of client or server failure. NLM requires that the server make 498 call backs to the client for certain scenarios and therefore is not 499 necessarily well suited for Internet firewall traversal. 501 Desirable features of file locking support are: 503 o Integration with the NFS protocol. 505 o Interoperability between operating environments. The protocol 506 should make a reasonable effort to support the locking semantics 507 of both PC and Unix clients and servers. 509 o Scalable solutions - thousands of clients. The server should 510 not be required to maintain client lock state across reboots. 512 o Internet capable (firewall traversal, latency sensitive). The 513 server should not be required to initiate TCP connections to 514 clients. 516 o Timely recovery in the event of client/server or network 517 failure. Server recovery should be rapid. The protocol should 518 allow clients to detect the loss of a lock. 520 CIFS supports file locking and DOS SHARE support. 522 NFSv4 NFSv4 Requirements October 1998 524 9. Internationalization 526 The current NFS protocols are limited in their support of anything 527 more than 7-bit ASCII strings. It is imperative that NFS support a 528 range of character sets. This can be provided by requiring support 529 for Unicode with a UTF-8 wire encoding. Therefore, all strings 530 defined as part of the NFS protocol will need to be defined as UTF-8 531 and the appropriate XDR encoding used. 533 NFSv4 NFSv4 Requirements October 1998 535 10. Bibliography 537 [RFC1094] 538 Sun Microsystems, Inc., "NFS: Network File System Protocol 539 Specification", RFC1094, March 1989. 541 ftp://ftp.isi.edu/in-notes/rfc1094.txt 543 [RFC1813] 544 Callaghan, B., Pawlowski, B., Staubach, P., "NFS Version 3 Protocol 545 Specification", RFC1813, Sun Microsystems, Inc., June 1995. 547 ftp://ftp.isi.edu/in-notes/rfc1813.txt 549 [RFC1831] 550 Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification 551 Version 2", RFC1831, Sun Microsystems, Inc., August 1995. 553 ftp://ftp.isi.edu/in-notes/rfc1831.txt 555 [RFC1832] 556 Srinivasan, R., "XDR: External Data Representation Standard", 557 RFC1832, Sun Microsystems, Inc., August 1995. 559 ftp://ftp.isi.edu/in-notes/rfc1832.txt 561 [RFC1833] 562 Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC1833, 563 Sun Microsystems, Inc., August 1995. 565 ftp://ftp.isi.edu/in-notes/rfc1833.txt 567 [RFC2025] 568 Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC2025, 569 Bell-Northern Research, October 1996. 571 ftp://ftp.isi.edu/in-notes/rfc2025.txt 573 [RFC2078] 574 Linn, J., "Generic Security Service Application Program Interface, 575 Version 2", RFC2078, OpenVision Technologies, January 1997. 577 NFSv4 NFSv4 Requirements October 1998 579 ftp://ftp.isi.edu/in-notes/rfc2078.txt 581 [RFC2203] 582 Eisler, M., Chiu, A., Ling, L., "RPCSEC_GSS Protocol Specification" 583 RFC2203, Sun Microsystems, Inc., August 1995. 585 ftp://ftp.isi.edu/in-notes/rfc2203.txt 587 [Sandberg] 588 Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh, B. Lyon, "Design 589 and Implementation of the Sun Network Filesystem," USENIX Conference 590 Proceedings, USENIX Association, Berkeley, CA, Summer 1985. The 591 basic paper describing the SunOS implementation of the NFS version 2 592 protocol, and discusses the goals, protocol specification and trade- 593 offs. 595 [X/OpenNFS] 596 X/Open Company, Ltd., X/Open CAE Specification: Protocols for X/Open 597 Internetworking: XNFS, X/Open Company, Ltd., Apex Plaza, Forbury 598 Road, Reading Berkshire, RG1 1AX, United Kingdom, 1991. This is an 599 indispensable reference for NFS version 2 protocol and accompanying 600 protocols, including the Lock Manager and the Portmapper. 602 [X/OpenPCNFS] 603 X/Open Company, Ltd., X/Open CAE Specification: Protocols for X/Open 604 Internetworking: (PC)NFS, Developer's Specification, X/Open Company, 605 Ltd., Apex Plaza, Forbury Road, Reading Berkshire, RG1 1AX, United 606 Kingdom, 1991. This is an indispensable reference for NFS version 2 607 protocol and accompanying protocols, including the Lock Manager and 608 the Portmapper. 610 NFSv4 NFSv4 Requirements October 1998 612 11. Author's Address 614 Address comments related to this memorandum to: 616 spencer.shepler@eng.sun.com -or- nfsv4-wg@sunroof.eng.sun.com 618 Spencer Shepler 619 Sun Microsystems, Inc. 620 7808 Moonflower Drive 621 Austin, Texas 78750 623 Phone: (512) 349-9376 624 E-mail: spencer.shepler@eng.sun.com