idnits 2.17.1 draft-ietf-nfsv4-requirements-01.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-24) 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 (September 1998) is 9353 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. -------------------------------------------------------------------------------- 2 Network Working Group Spencer Shepler 3 Internet Draft September 1998 4 Document: draft-ietf-nfsv4-requirements-01.txt 6 NFS Version 4 Requirements 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference 18 material or to cite them other than as "work in progress." 20 To view the entire list of current Internet-Drafts, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 23 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 24 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 26 Abstract 28 With the creation of the NFS version 4 working group, a set of 29 requirements for the next version of NFS must be codified to create a 30 reasonable context for the new protocol discussions and aide in the 31 upcoming decisions. This Internet Draft has the purpose of 32 presenting the requirements for NFS version 4 and will be used as the 33 leading document for NFSv4 working group. 35 NFSv4 NFSv4 Requirements September 1998 37 Table of Contents 39 1. NFS Version 4 Requirements . . . . . . . . . . . . . . . . . 3 40 2. Ease of implementation or complexity of protocol . . . . . . 3 41 2.1. Extensibility / layering . . . . . . . . . . . . . . . . . 3 42 2.2. Managed Extensions or Minor Versioning . . . . . . . . . . 3 43 3. Reliable and Available . . . . . . . . . . . . . . . . . . . 4 44 4. Scalable Performance . . . . . . . . . . . . . . . . . . . . 4 45 4.1. Throughput and Latency on the Network . . . . . . . . . . 5 46 4.2. Server Work Load or Scalability . . . . . . . . . . . . . 5 47 4.3. Client Caching . . . . . . . . . . . . . . . . . . . . . . 5 48 4.4. Disconnected Client Operation . . . . . . . . . . . . . . 6 49 5. Interoperability . . . . . . . . . . . . . . . . . . . . . . 6 50 5.1. Platform Specific Behavior . . . . . . . . . . . . . . . . 6 51 5.2. Additional or Extended Attributes . . . . . . . . . . . . 6 52 5.3. Access Control Lists . . . . . . . . . . . . . . . . . . . 7 53 6. RPC Mechanism and Security . . . . . . . . . . . . . . . . . 8 54 6.1. Remote Procedure Call Mechanism . . . . . . . . . . . . . 8 55 6.2. User identification . . . . . . . . . . . . . . . . . . . 8 56 6.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 6.3.1. Authentication . . . . . . . . . . . . . . . . . . . . . 9 58 6.3.2. Data Integrity . . . . . . . . . . . . . . . . . . . . 10 59 6.3.3. Data Privacy . . . . . . . . . . . . . . . . . . . . . 10 60 6.3.4. Security Mechanisms . . . . . . . . . . . . . . . . . 10 61 6.3.5. Security Negotiation . . . . . . . . . . . . . . . . . 10 62 7. Internet Accessibility . . . . . . . . . . . . . . . . . . 10 63 7.1. Congestion Control and Transport Selection . . . . . . . 11 64 7.2. Firewalls and Proxy Servers . . . . . . . . . . . . . . 11 65 7.3. Multiple RPCs and Latency . . . . . . . . . . . . . . . 11 66 8. File locking / recovery . . . . . . . . . . . . . . . . . 12 67 9. Internationalization . . . . . . . . . . . . . . . . . . . 13 68 10. Bibliography . . . . . . . . . . . . . . . . . . . . . . 14 69 11. Author's Address . . . . . . . . . . . . . . . . . . . . 16 71 NFSv4 NFSv4 Requirements September 1998 73 1. NFS Version 4 Requirements 75 As stated in the charter the first deliverable for the NFS version 4 76 working group is this requirements document. This document is to 77 cover the "limitations and deficiencies of NFS version 3". Therefore 78 the intent of the following sections is to identify the various 79 feature points of NFS as a distributed file system and discuss its 80 current functionality and compare to other distributed file systems 81 and offer reasonable requirements for each of these areas. 83 2. Ease of implementation or complexity of protocol 85 One of the strengths of NFS has been the ability to implement a 86 client or server with relative ease. The eventual size of a basic 87 implementation is relatively small. The main reason for keeping NFS 88 as simple as possible is that a simple protocol design can be 89 described in a simple specification that promotes straightforward, 90 interoperable implementations. All protocols can run into problems 91 when deployed on real networks, but simple protocols yield problems 92 that are easier to diagnose and correct. 94 2.1. Extensibility / layering 96 With NFS' relative simplicity, the addition or layering of 97 functionality has been easy to accomplish. The addition of features 98 like the client automount or autofs, client side disk caching and 99 high availability servers are examples. This type of extensibility 100 is desirable in an environment where problem solutions do not require 101 protocol revision. This extensibility can also be helpful in the 102 future where unforeseen problems or opportunities can be solved by 103 layering functionality on an existing set of tools or protocol. 105 2.2. Managed Extensions or Minor Versioning 107 For those cases where the NFS protocol is deficient or where a minor 108 modification is the best solution for a problem, a minor version or a 109 managed extension could be helpful. There have been instances with 110 NFS version 2 and 3 where small straightforward functional additions 111 would have increased the overall value of the protocol immensely. 112 However, the perceived size and burden of using a change of RPC 113 version number for the introduction of new functionality led to no or 114 slow change. It is possible that a new NFS protocol could allow for 115 the rare instance where protocol extension within the RPC version 117 NFSv4 NFSv4 Requirements September 1998 119 number is the most prudent course and an RPC revision would be 120 unnecessary or impractical. 122 The areas of an NFS protocol which are most obviously volatile are 123 new orthogonal procedures, new well-defined file or directory 124 attributes and potentially new file types. It is possible and highly 125 desirable that these types of additions can be done without changing 126 the overall design model of NFS without significant effort or delay. 127 This is particularly true in adding new procedures. 129 A strong consideration should be given to a NFS protocol mechanism 130 for the introduction of this type of new functionality. This is 131 obviously in contrast to using the standard RPC version mechanism to 132 provide minor changes. The process of using RPC version numbers to 133 introduce new functionality brings with it a lot of history which may 134 not technically prevent its use. However, the historical issues 135 involved will need to be addressed as part of the NFS protocol work 136 to increase the chance of current and future success of the protocol. 138 3. Reliable and Available 140 Current NFS protocol design has lead to quick recovery from server 141 and client failure. This approach to the design has lent itself well 142 to layered technologies like high availability and clustered servers. 143 Providing a protocol design approach that lends itself to these types 144 of reliability and availability features is very desirable. 146 For the next version of NFS, consideration should be given to client 147 side availability schemes such as client switching between or fail- 148 over to available server replicas. If possible, the protocol should 149 allow for or ease the building of such layered solutions. 151 4. Scalable Performance 153 In designing and developing an NFS protocol from a performance 154 viewpoint there are several different points to consider. Each can 155 play a significant role in perceived and real performance from the 156 user's perspective. The three main areas of interest are: throughput 157 and latency on the network, server work load or scalability and 158 client side caching. 160 NFSv4 NFSv4 Requirements September 1998 162 4.1. Throughput and Latency on the Network 164 NFS currently has characteristics that provide good throughput for 165 the reading and writing of file data. However, the number of RPCs 166 required to accomplish some tasks combined with high latency network 167 environments leads to sluggish response. The protocol should 168 continue to provide good raw read and write throughput while 169 addressing the issue of network latency. This issue is discussed 170 further in the section on Internet Accessibility. 172 4.2. Server Work Load or Scalability 174 Current NFS operations are relatively lightweight in that the 175 processing work for most of the operations is not CPU intensive. 176 This allows for potential support of a large number of clients. This 177 attribute can also be helpful in building efficient and scalable SMP 178 or cluster based servers. While this type of protocol design 179 (lightweight operations) is desirable, it needs to be balanced 180 against the previous issue of having the client generate a large 181 number of RPCs to accomplish a straight forward task. 183 4.3. Client Caching 185 In an attempt to speed response time and to reduce network and server 186 load, NFS clients have always cached directory and file data. 187 However, this has usually been done as memory cache and in relatively 188 recent history, local disk caching has been added. 190 Having the client cache directory and file data is very desirable. 191 Other distributed file systems have shown that aggressive client side 192 caching can be very visible to the end user in response time gains. 193 Client caching is increasingly important for Internet environments 194 where throughput can be limited and response time can grow 195 significantly. 197 The NFS protocol should allow for aggressive caching while balancing 198 the needs for simplicity and Internet accessibility (i.e. firewalls). 199 If possible, the caching ability should be layered on the protocol 200 instead of embedding specific client caching functions in the 201 protocol itself. 203 NFSv4 NFSv4 Requirements September 1998 205 4.4. Disconnected Client Operation 207 An extension of client caching is the idea or functionality of 208 disconnected operation at the client. With the ability to cache 209 directory and file data aggressively, a client could then provide 210 service to the end user while disconnected from the server or 211 network. 213 While very desirable, disconnected operation has the opportunity to 214 inflict itself upon the NFS protocol in an undesirable way as 215 compared to traditional client caching. Given the complexities of 216 disconnected client operation and subsequent resolution of client 217 data modification through various playback or data selection 218 mechanisms, disconnected operation should not be a requirement for 219 the NFS effort. Even so, the NFS protocol should consider the 220 potential layering of disconnected operation solutions on top of the 221 NFS protocol (as with other server and client solutions). The 222 experiences with Coda, disconnected AFS and others should be helpful 223 in this area. 225 5. Interoperability 227 The NFS protocols are available for many different operating 228 environments. Even though this shows the protocol's ability to 229 provide distributed file system service for more than a single 230 operating system, the design of NFS is certainly Unix centric. The 231 next NFS protocol needs to be more inclusively of platform or file 232 system features beyond those of traditional Unix. 234 5.1. Platform Specific Behavior 236 Because of its Unix centric design, some of the protocol requirements 237 have been difficult to implement in some environments. For example, 238 persistent file handles (unique identifiers of file system objects), 239 Unix uid/gid mappings, directory modification time, accurate file 240 sizes, file/directory locking semantics (SHAREs, PC-style locking). 242 5.2. Additional or Extended Attributes 244 NFS Versions 2 and 3 do not provide for file or directory attributes 245 beyond those that are found in the traditional Unix environment; for 246 example the user identifier/owner of the file, a permission or access 247 bitmap, time stamps for modification of the file or directory and 249 NFSv4 NFSv4 Requirements September 1998 251 file size to name a few. While the current set of attributes has 252 usually been sufficient, the file system's ability to manage 253 additional information associated with a file or directory can be 254 useful. 256 There are many possibilities for additional attributes in the next 257 version of NFS. Some of these include: object creation timestamp, 258 user identifier of file's creator, timestamp of last backup or 259 archival bit, version number, file content type (MIME type), 260 existence of data management involvement (i.e. DMAPI). 262 This list is representative of the possibilities and are meant to 263 show the need for an additional attribute set. Enumerating the 264 'correct' set of attributes is difficult and is one of the reasons 265 for looking towards minor versioning as a way to provide needed 266 extensibility. Another way to provide some extensibility is in 267 providing support for a generalized named attribute mechanism. This 268 mechanism would allow a client to name, store and retrieve arbitrary 269 data and have it associated as an attribute of a file or directory. 270 This type of extended attribute mechanism brings with it a large set 271 of issues that will need to be addressed in the protocol 272 specification while keeping the overall goal of simplicity in mind. 274 There are operating environments that provide named or extended 275 attribute mechanisms. Digital Unix provides for the storage of 276 extended attributes with some generalized format. HPFS and NTFS also 277 provide for named data associated with traditional files. SGI's 278 local file system, XFS, also provides for this type of name/value 279 extended attributes. However, there does not seem to be a clear 280 direction that can be taken from these or other environments. 282 5.3. Access Control Lists 284 Access Control Lists (ACL) can be viewed as one specific type of 285 extended attribute. This attribute is a designation of user access 286 to a file or directory. Many vendors have created ancillary 287 protocols to NFS to extend the server's ACL mechanism across the 288 network. Generally this has been done for homogeneous operating 289 environments. Even though the server still interprets the ACL and has 290 final control over access to a file system object, the client is able 291 to manipulate the ACL via these additional protocols. 293 Other distributed file systems have also provided ACL support. DFS, 294 AFS and CIFS to name a few. Based on current capabilities, it seems 295 to be a requirement that NFS provide this capability as well but the 296 major issue is one of compatibility. It may be problematic to create 297 a workable ACL mechanism that will encompass a reasonable set of 299 NFSv4 NFSv4 Requirements September 1998 301 functionality for all operating environments. 303 The three major reasons behind providing ACL support are existing 304 distributed file system support, file servers not providing native 305 environment for user management of ACLs and perception of ACL support 306 as part of security requirement. Even with the complicated nature of 307 ACL support it is still worthwhile to work towards a solution that 308 can at least provide basic functionality for the user. 310 6. RPC Mechanism and Security 312 NFS relies on the underlying security mechanisms provided by the 313 ONCRPC protocol. Until the introduction of the ONCRPC RPCSEC_GSS 314 security flavor, NFS security was generally limited to none 315 (AUTH_SYS) or DES (AUTH_DH). The AUTH_DH security flavor was not 316 successful in providing readily available security for NFS because of 317 a lack of implementation and deployment. Also the 192 bit public 318 keys modulos used for the AUTH_DH security flavor quickly became too 319 small for reasonable security. 321 6.1. Remote Procedure Call Mechanism 323 The ONCRPC protocol provides the basic NFS foundation for the 324 following reasons: 326 o Open protocol definition managed by IETF 328 o Transport independent (i.e. UDP and TCP supported) 330 o Simple data representation and procedure encoding models 332 o Various security mechanisms available through use of RPCSEC_GSS 334 6.2. User identification 336 NFS has been limited to the use of the Unix centric user 337 identification mechanism of numeric user id based on the available 338 file system attributes and the use of the ONCRPC. However, for NFS 339 to move beyond the limits of large work groups, user identification 340 should be string based and the definition of the user identifier 341 should allow for integration into an external naming service or 342 services. 344 NFSv4 NFSv4 Requirements September 1998 346 Internet scaling should also be considered for this as well. The 347 identification mechanism should take into account multiple naming 348 domains and other extremes that can be presented by use outside of 349 the work group. 351 If NFS is to move among various naming and security services, it may 352 be necessary to stay with a string based identification. This would 353 allow for servers and clients to translate between the external 354 string representation to a local or internal numeric (or other 355 identifier) which matches internal implementation needs. 357 DFS uses a string based naming scheme but translates the name to a 358 UUID (16 byte identifier) that is used for internal protocol 359 representations. The DCE/DFS string name is a combination of cell 360 (administrative domain) and user name. As mentioned, NFS clients and 361 servers map a Unix user name to a 32 bit user identifier that is then 362 used for ONCRPC and NFS protocol fields requiring the user 363 identifier. 365 6.3. Security 367 As a result of a lack of implementation and deployment and relatively 368 weak protection, authentication has been a major issue for ONCRPC and 369 hence NFS. With the introduction of the RPCSEC_GSS security flavor, 370 ONCRPC can provide for reasonable authentication along with integrity 371 and privacy, if desired. The RPCSEC_GSS framework will allow the use 372 of both public and private key mechanisms. Therefore, NFS as a user 373 of ONCRPC should state its specific requirements for each of these 374 areas. 376 In comparison, AFS and DFS provide strong authentication mechanisms. 377 CIFS does provide authentication at initial server contact but does 378 not continue this authentication during subsequent interaction. 380 6.3.1. Authentication 382 Strong authentication is a requirement for NFS and the logical 383 solution for this is in the use of ONCRPC and RPCSEC_GSS. This 384 solution will allow for both private and public key mechanisms to be 385 employed if required. This flexibility will allow for security 386 usability in varying environments. 388 NFSv4 NFSv4 Requirements September 1998 390 6.3.2. Data Integrity 392 Since file and directory data is the essence of distributed file 393 service, the NFS protocol should provide to the users of the file 394 service a reasonable level of data integrity. The RPCSEC_GSS 395 mechanism provides a framework for data integrity and the security 396 mechanisms chosen for NFS should be implemented to provide data 397 integrity. 399 6.3.3. Data Privacy 401 Data privacy, while desirable, is not as important in all 402 environments as authentication and integrity. Data privacy should be 403 an available option within NFS but not a requirement. 405 6.3.4. Security Mechanisms 407 With the use of the RPCSEC_GSS framework, both public and private 408 mechanisms can and should be provided by NFS. The choice from both 409 public and private key mechanisms will allow for the appropriate 410 choice being made by the user based on factors within their 411 environment. 413 Potential choices for the private key mechanism would be Kerberos V5 414 and for the public key choice, SPKM [RFC2025] is available. 416 6.3.5. Security Negotiation 418 With both private and public key mechanisms available to the end 419 user, the NFS server and client will need a method to negotiate 420 appropriate usage based on availability and policy. This negotiation 421 should account for authentication, integrity, and privacy so that 422 administrators and users can employ the appropriate security policies 423 for their environments. 425 7. Internet Accessibility 427 Being a product of an IETF working group, the NFS protocol should not 428 only be built upon IETF technologies where possible but should also 430 NFSv4 NFSv4 Requirements September 1998 432 work well within the broader Internet environment. 434 7.1. Congestion Control and Transport Selection 436 As with any network protocol, congestion control is a major issue and 437 the transport mechanisms that are chosen for NFS should take this 438 into account. Traditionally implementations of NFS have been 439 deployed using both UDP and TCP. With the use of UDP, most 440 implementations provide a rudimentary attempt of congestion control 441 with simple back-off algorithms and round trip timers. While this 442 may be sufficient in today's NFS deployments, as an Internet protocol 443 NFS will need to ensure sufficient congestion control or management. 445 With congestion control in mind, NFS must use TCP as a transport (via 446 ONCRPC). The UDP transport provides its own advantages in certain 447 circumstances. In today's NFS implementations, UDP has been shown to 448 produce greater throughput as compared to similarly configured 449 systems that use TCP. If UDP is to be supplied as an NFS transport 450 mechanism, then the issues of congestion control must be dealt with. 452 7.2. Firewalls and Proxy Servers 454 NFS's protocol design should allow its use via Internet firewalls. 455 The protocol should also allow for the use of file system proxy/cache 456 servers. Proxy servers can be very useful for scalability and other 457 reasons. The NFS protocol needs to address the need of proxy servers 458 in a way that will deal with the issues of security, access control, 459 and content control. It is possible that these issues can be 460 addressed by documenting the related issues of proxy server usage. 461 However, it is likely that the NFS protocol will need to support 462 proxy servers directly through the NFS protocol. In any case, the 463 NFS proxy server should be considered during protocol development. 465 7.3. Multiple RPCs and Latency 467 As an application at the NFS client performs simple file system 468 operations, multiple NFS operations or RPCs may be executed to 469 accomplish the work for the application. While the NFS version 3 470 protocol addressed some of this by returning file and directory 471 attributes for most procedures hence reducing follow up GETATTR 472 requests, there is still room for improvement. Reducing the number 473 of RPCs can lead to a reduction of processing overhead on the server 474 (transport and security processing) along with reducing the time 476 NFSv4 NFSv4 Requirements September 1998 478 spent at the client waiting for the server's individual responses. 479 This issue is more prominent in environments with larger degrees of 480 latency. 482 The CIFS file access protocol supports 'batched requests' that allow 483 multiple requests to be batched and therefore reducing the number of 484 round trip messages between client and server. 486 This same approach can be used by NFS to allow the grouping of 487 multiple procedure calls together in a traditional RPC request. Not 488 only would this allow for the reduction in protocol imposed latency 489 but would reduce transport and security processing overhead and could 490 allow a client to complete more complex tasks by combining 491 procedures. 493 8. File locking / recovery 495 NFS has provided Unix file locking and DOS SHARE capability with the 496 use of an ancillary protocol (Network Lock Manager / NLM). The NLM 497 protocol provides for file locking and recovery of those locks in the 498 event of client or server failure. NLM requires that the server make 499 call backs to the client for certain scenarios and therefore is not 500 necessarily well suited for Internet firewall traversal. 502 Desirable features of file locking support are: 504 o Integration with the NFS protocol 506 o Interoperability between operating environments (i.e. 507 traditional NFS, CIFS, DFS, Novell environments) 509 o Scalable solutions - thousands of clients 511 o Internet capable (firewall traversal, latency sensitive) 513 o Timely recovery in the event of client/server failure or cluster 514 fail-over. 516 DFS offers file locking but does not provide DOS SHARE 517 capability. DFS' relies on the server calling back to the 518 client for the file locking functionality. 520 CIFS supports file locking and DOS SHARE support. 522 NFSv4 NFSv4 Requirements September 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 September 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 September 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 September 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