From nfs4-wg-request Mon Nov 11 09:26:25 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05678; Mon, 11 Nov 96 09:26:26 PST Return-Path: Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05674; Mon, 11 Nov 96 09:26:25 PST Received: from notnerb by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA11125; Mon, 11 Nov 1996 09:19:19 -0800 Date: Mon, 11 Nov 1996 09:18:51 -0800 (PST) From: Brent Callaghan Reply-To: Brent Callaghan Subject: re: Internationalization and NFS V4 To: glenn@spyglass.com Cc: nfs4-wg@sunroof Message-Id: Content-Type: text X-Sun-Text-Type: ascii Status: RO Content-Length: 2167 Lines: 59 Hello Glenn, We've already had email discussions within Sun on this topic, and there's consensus that V4 should certainly support Unicode (perhaps in its UTF-8 flavor) for pathnames. As for other identifiers, NFS V2/V3 doesn't have knowlege of hostnames, usernames, etc though that could be different in V4. Thanks for your comments. I've forwarded to the nfs4-wg alias. Since you obviously have an interest in this topic, we would appreciate your participation in further discussions. Send mail to nfs4-wg-request@sunroof.eng.sun.com if you'd like to be added to the NFS V4 working group alias. Brent >----------------Begin Forwarded Message----------------< Date: Mon, 11 Nov 1996 12:00:41 -0400 From: "Glenn Adams" Subject: webnfs-review@terra.Eng.Sun.COM To: brent.callaghan@Eng >Date: Fri, 8 Nov 1996 17:01:47 -0800 >From: brent.callaghan@Eng.Sun.COM (Brent Callaghan) >We have decided to begin work on NFS version 4. I would hope that one of the principal features you attempt to address in V4 is the problem of internationalization; in particular, the issue of incompatible (and untagged) character encodings for pathnames. The best way to solve this would be to adopt some form of ISO/IEC 10646 (a.k.a. Unicode), perhaps UTF-8, as the canonical on-the-wire encoding for all pathnames. This would be consistent with the recently agreed upon recommendations by the IAB Character Set Adhoc which advocates this approach. While you're at it, you might adopt UTF-8 for the encoding of domain entity names such as hostnames, usernames, passwords, etc. This would be a proactive move looking forward to a time in which we have an internationalized DNS. Such a strategy would serve to leverage Java's use of Unicode and, at the same time, solve (for good) one of the hairy problems of Worldwide Internetworking. It would also dovetail nicely with a move by Microsoft, Netscape, Spyglass and other companies to adopt UTF-8 as a standard, default encoding for URLs. Regards, Glenn Adams Technical Director, Unicode Consortium Globalilization Architect, Spyglass, Inc. >----------------End Forwarded Message----------------< From nfs4-wg-request Mon Nov 11 10:30:55 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06027; Mon, 11 Nov 96 10:30:56 PST Return-Path: Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06023; Mon, 11 Nov 96 10:30:55 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA18274; Mon, 11 Nov 1996 10:23:53 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA04545 for ; Mon, 11 Nov 1996 10:23:52 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA00644; Mon, 11 Nov 1996 13:19:00 -0500 (EST) Received: by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA28081; Mon, 11 Nov 1996 13:19:11 -0500 Date: Mon, 11 Nov 1996 13:19:11 -0500 From: Eric Werme USG Message-Id: <9611111819.AA28081@wasted.zk3.dec.com> To: nfs4-wg@sunroof.eng.sun.com Subject: Please add werme@zk3.dec.com Status: RO Content-Length: 37 Lines: 3 to the WG mailing list. -Ric Werme From nfs4-wg-request Wed Nov 13 18:39:32 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09624; Wed, 13 Nov 96 18:39:34 PST Return-Path: Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09620; Wed, 13 Nov 96 18:39:32 PST Received: from terra.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA03683; Wed, 13 Nov 1996 18:32:30 -0800 Received: by terra.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA28564; Wed, 13 Nov 1996 18:29:44 -0800 Date: Wed, 13 Nov 1996 18:29:44 -0800 From: brent@jurassic (Brent Callaghan) Message-Id: <199611140229.SAA28564@terra.eng.sun.com> To: nfs4-wg@sunroof Subject: Test - do not read X-Sun-Charset: US-ASCII Status: RO Content-Length: 6 Lines: 2 Test From nfs4-wg-request Fri Nov 22 13:38:32 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00512; Fri, 22 Nov 96 13:38:33 PST Return-Path: Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00508; Fri, 22 Nov 96 13:38:32 PST Received: from terra.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA14362; Fri, 22 Nov 1996 13:31:17 -0800 Received: by terra.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA05519; Fri, 22 Nov 1996 13:28:06 -0800 Date: Fri, 22 Nov 1996 13:28:06 -0800 From: brent@jurassic (Brent Callaghan) Message-Id: <199611222128.NAA05519@terra.eng.sun.com> To: nfs4-wg@sunroof Subject: NFS V4 BOF Thurs 12th: Come early! X-Sun-Charset: US-ASCII Status: RO Content-Length: 587 Lines: 26 If you're planning on attending the NFS V4 BOF, you may need to come early if you'd like the comfort of a seat (see attached mail) The BOF is scheduled 9:00-11:30am Thurs 12th at the Fairmont in San Jose. For registration information, check out the web page: http://www.ietf.org/meetings/SanJose.html The BOF and WG schedule for the week is available via: ftp://ftp.ietf.org/ietf/0mtg-agenda.txt and the NFS V4 Working Group charter and agenda are available via: ftp://ftp.ietf.org/ietf/96dec/nfs-agenda-96dec.txt See you there. Brent ----- Begin Included Message ----- From scoya@ietf.org Fri Nov 22 12:31:18 1996 To: wgchairs@ietf.org, bofchairs@ietf.org Subject: And you thought Montreal was crowded! Status: RO Content-Length: 1339 Lines: 40 Greetings, It is with DEEP regret that I confirm the rumors about the San Jose meeting: it will be crowded. As of now, there are over 1250 people registered. And, we have NO IDEA which groups they will be attending. It could be yours... or yours... or YOURS! Marcia made an extrodinary effort to get large meeting rooms at other hotels close to the Fairmont. No luck there... must have something to do with San Jose and Christmas (the parade is Saturday, btw :-) We're hoping that the multicast sessions can be piped through the hotel's internal cable system. But as you all will observe, we have no idea what the interests of all these folks will be, and it may be in sessions that are not being multicasted. One of the things we'll be doing is having the hotel REMOVE the last couple rows of chairs- yes, I said remove. This will accommodate more people, albeit standing. As session chairs, you have a lot of discretion on how the meetings are conducted. Let me give you another tool... uh, suggestion: Reserve the first couple rows of chairs for your primary (active) participants. I don't want key people not being able to fit into a room. Again, this is just a suggestion. I will be informing all those who attend the Newcomers' orientation Sunday afternoon that this may happen. Steve ----- End Included Message ----- From nfs4-wg-request Mon Dec 2 11:14:26 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05106; Mon, 2 Dec 96 11:14:29 PST Return-Path: Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05102; Mon, 2 Dec 96 11:14:26 PST Received: by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA12635; Mon, 2 Dec 1996 11:06:57 -0800 Date: Mon, 2 Dec 1996 11:06:57 -0800 From: mre@jurassic (Michael R. Eisler) Message-Id: <199612021906.LAA12635@jurassic.eng.sun.com> To: nfs4-wg@sunroof.eng.sun.com Subject: Kick-off discussion Status: RO Content-Length: 20734 Lines: 515 I've prepared a document that outlines some of things folks at Sun want to do with NFS Version 4. This is simply a proposal and can be used as a basis for starting discussion. -mre --- cut here --- NFS V4 Outline/Mike Eisler mre@Eng.Sun.Com/December 2, 1996 The document is a *proposed* outline for "pull" items that justify NFS Version 4. An NFS Version 4 would address four areas: - internationalization - facilitate operation on the internet - improved security semantics - embrace non-UNIX systems, especially clients - versioning Clearly, features that improve NFS' position in the above areas can be considered pull items. The executive summary of the NFS V4 feature list is: - support for non-ASCII character sets - add features to reduce round trips - fold locking (using a Spritely-NFS-like token protocol) into NFS Version 4 - add extended attributes (including ACLs) - get rid of the MOUNT protocol and replace it with in-band browsing, and security parameters negotiation - replace the public file handle concept with explicit options to LOOKUP to support multi-component lookup, mount point crossing, and symbolic link following. - provide for expandability within NFS Version 4. Internationalization ==================== Whether this is Unicode, or UTF-8, or something else, NFS should explicitly cope with non-US-ASCII character sets. Facilitate operation on the internet ==================================== WebNFS was conceived as a way enable NFS clients to access servers through firewalls. WebNFS has it's limitations though: - no way to query a NFS server for its list of exported file systems - no way to negotiate security flavors. Not only is this a problem once the NFS session is establish, but there an issue (and potential security hole) with what security flavor should be used on WebNFS multi-component lookups (and for that matter, path name to file handle resolutions on the MOUNT protocol). - relative URLs that cross mount points might not work on NFS servers that adhere to the NFS Version 2 and 3 specifications - A minor issue is the usurping of an all zeroes or zero-length file handle as a key for indicating WebNFS semantics. With a protocol rev, this can be fixed. - no locking query for exported file systems ------------------------------- It is proposed that the MOUNT protocol not be used for boot strapping NFS Version 4 client/server sessions, and in its place, a new procedure, SHAREINFO, be added. The SHAREINFO procedure would return the list of exported file systems (by path name). The MOUNT protocol has other procedures, which it is proposed that the NFS V4 protocol not include: - allow a client to inform the server that it has unmounted the file system. - allow a client to see which clients are mounting which file systems of the server. These features have been a source of perennial problems, due to NFS' stateless nature. It is also the case that they provide a useful if inaccurate source of information to administrators. Equivalent and more accurate information can be gathered if the server implements logging or caches of the most recent accesses from NFS clients. A separate and optional administration protocol (perhaps, MOUNT version 4) is more appropriate for this task. security flavor negotiation --------------------------- The new SHAREINFO procedure will return security information in addition to path names of exported file systems. It will also return flavor specific information to further narrow down security parameters that the client must use. The reason is that security flavors like RPCSEC_GSS that multiplex different parameters on on flavor number can be cleanly supported. NFS Version 4 will specify the security flavor specific formats for each commonly used flavor. When new flavors are specifying new formats will be added as necessary. For those clients that don't use SHAREINFO (for example, they arrive at the server via an NFS url), it would be useful to let them negotiate security outside of SHAREINFO for specific object they are accessing. It is proposed that a new error code, NFS4ERR_SEC_MISMATCH, be added. This code will be returned whenever security parameters used in the RPC credential of the call is different than how the targeted file is exported. Should a NFS client get back this error, a new procedure, SECINFO, can be used to determine what security parameters the NFS client should use in the credential. The results of SECINFO would be the same as the security information included for each file system in a SHAREINFO results, and would include: - whether the client has read or read-write access - the flavor to be used, - any flavor specific parameters By include the security information in the SHAREINFO, a client then what security should be used to resolve the path name. relative URLS, mount point crossing, and well known file handles --------------------------------------------------------------- It is proposed that NFS V4's LOOKUP procedure (actually, the diropargs3 struct would be extended, thereby affecting all procedures that use component or path names) be enhanced in these ways: - add a descriptor that states whether the LOOKUP is to be done from the directory file handle of in call; from the "floating" or "virtual" root that the administrator has defined, or from the absolute root of the server's local file system hierarchy. This gets rid of the overloading the file handle as a specifier of LOOKUP semantics. - add a flags word that indicates whether multicomponent lookup is being used, whether mount point crossing should be used, and whether symbolic link following should be done. This gives WebNFS clients the opportunity to use a set of semantics that might differ from what a "conventional" NFS client might use. The enhanced LOOKUP would be enough to replace the existing MNT procedure of the MOUNT protocol. The results of a SHAREINFO procedure would include the control information described above, so that file systems can be exported from the absolute or relative roots, or relative to a specific file handle. locking ------- Currently locking is a side-band protocol listening on a floating port, thus unsuitable for some firewalls. Locking should be combined with filing in NFS V4. Since NLM is broken, if we fold locking into NFS, it is proposed that the token based scheme described in Mogul's papers on Spritely NFS be used for lock state. David Robinson once proposed a lease approach and when Mike Eisler described this to Kirk McKusick, his objection was that UNIX applications do not cope very well with lost locks. A lock lost infrequently due to a token embargo (or a with the current NLM scheme, a missed window in the server recovery phase) is one thing. But a lock lost due to failure to renew before lease expiration is going to produce lots of lost locks and thus lots of application breakage. Using long leases is a way to mitigate breakage, but recall that server recovery time is bounded by the length of the longest lease outstanding. compound operations ------------------ Consider that when an http client resolves a url, it just needs to do: GET path_name --> <-- contents of html file WebNFS must do: LOOKUP fh=0x0 path_name --> <-- response fh READ fh --> <-- contents of file A generic COMPOUND procedure that would cascade successive operations would eliminate this. Brent Callaghan has proposed: COMPOUND: PUTFH 0x0123456; LOOKUP "foo"; GETFH; READ 0 32768 --> <-- fh of "foo", contents of file In the above example, the file, "foo" relative to fh 0x123456 is read. PUTFH and GETFH are pseudo operations that indicate when to interject or extract a fh into or from (respectively) the arguments or results (respectively). Improved Security Semantics =========================== The discussion above has already covered much of the security issues and solutions. Remaining problems are: - lack of in-band ACL support. This could be solved under the umbrella of extended attributes. - uid and gid name space. NFS attributes describe file owners as 32 bit integers. This causes two problems: - scalability - 2^32 is a smaller number than the number of humans. Even if it weren't, it is no unreasonable to suppose situations where file owners might be nonhuman entities. - global name space. If the uid's returned in attributes are to make sense, the assignment of uids must be done globally. They aren't done globally, so when a user from one organization accesses a files from another organization, he encounters uid conflicts. Rather than manipulating numbers, it might be better to manipulate user names. One possible solution would be to have GETATTR return file ownership in terms of the principal name format corresponding to the RPC security flavor used. For example, AUTH_KERB5 uses Kerberos principal names. If GETATTR is done with AUTH_KERB4 in the RPC header, then, if the client so specifies, the file owner could be listed as say "mre@Eng.Sun.Com". How group ids are handled is an open issue, but could be worked around by just creating fake Kerberos principals for each group a server supports. The benefit of this approach is that NFS can leverage any scheme that the RPC layer is already using to map names to uids. Non-UNIX systems ================ [ Note this section has a PC-centric slant ] Export inheritance ------------------ The NFS protocol is specified to not let a NFS client cross mount points. This is so the NFS client does not get confused about the identity of files in the even two files on two different server file systems share the same file id (inode #). This semantic is not desired by some clients, such as PC desk tops. The proposal, as described previously, is to make mount point crossing optional. COPY procedure -------------- It is believed that some operating systems, such as those on PCs, includes a file COPY interface, and that this interfaces is frequently used. If so, a COPY procedure should be added. Mandatory locking ----------------- PCs apparently have a form of mandatory locking that differs from UNIX mandatory locking. It would be nice to cope with this. Extended Attributes ------------------- A "hidden" and "archive" bit would be useful to PCs using NFS. Case Sensitivity ---------------- NFS V3 allows servers to tell clients whether they are case-preserving and/or case-sensitive. The protocol doesn't solve the problem of determining case according to a particular character set ... the server really has no idea what character set a file name is stored in it's local file system's directory. Case mapping on U.S. ASCII is trivial. But even on 8 bit character sets, this is nontrivial. PCs demand case insensitive and case preserving semantics. An objection in the past of letting clients specify the case semantics on LOOKUPS and other operations that use component names is that this becomes a server-intensive burden. A compromise would be to allow, but not force, server to offer the option of case-insensitive and case-mapping semantics. The NFS V4 protocol would let a server return, say via FSINFO, its preferred case semantics and whether it will let clients override these preferences. Clients would then be able to specify the case semantics on NFS requests. Note that this would require explicit support for non-U.S.-ASCII character sets; if the server doesn't know what character set is being used, it cannot do a case-insensitive lookup, or a case-mapping create. Opportunistic locking --------------------- This is an idea borrowed from SMB. Locking can be made efficient if the client always tries to lock an entire file, even if the application is locking just a part of the file. If the client gets the lock, then it can cache the file at will. If someone else later wants to lock the file, the server tells the first client that it must case "opportunistic locking", and lock the file using record locking (after flushing any dirty bits in its cache). Minor Versioning ================ On several occasions, it would have been convenient to just add procedures to the a version of the NFS protocol. In NFS Version 2, adding a procedure to do safe asynchronous writes were needed almost immediately. Had we been able to do this, the NFS performance story might never have had a black mark. A cleaner way to add procedures without revising the version number of the NFS program would be helpful. Successive minor versions would be used to just add procedures, not renumber, modify (except perhaps in ways that don't impact backward compatibility, such as adding bits to a flag word) or delete them, including procedures added in an intermediate minor version. If a procedure modification or deletion is necessary, the NFS program version number would have to be changed from 4 to 5. Minor version numbers would have to be agreed upon by the same body that agrees upon NFS Version 4. An implementation would not be permitted to unilaterally add procedures. To negotiate the minor version number, it is proposed that a new procedure, GETMINORVERS be added, which indicates the highest minor version number that the NFS Version 4 server supports. GETMINORVERS will also return a vector of the supported procedures, thereby allowing a client to know up front if a server, say supports operations on symbolic links. By supporting a minor versioning, the body that establishes the NFS Version 4 protocol can quickly develop base functionality, and defer contentious issues and/or not well understood solutions. Extended Attributes =================== Extended attributes come in two flavors: (1) "named" attributes that use string names. Clients and servers could create new named attributes on the fly. The meaning of each attribute would be defined by the application. In a sense, these attributes are like micro-files, and the file with named attributes is the place holder for a directory of these "micro-files". Even if a client application doesn't recognize a particular named attribute, it should be able to at least dump it, hence using a string name, that the user might be able to parse. (2) "numbered" attributes used integers to represent the attributes. The definition of each numbered attribute would well-defined in the NFS V4 protocol (or in a minor version of NFS V4). In addition to operations for getting, setting and deleting attributes, there should be operations for listing attributes on a file. In one operation, one should be able to retrieve multiple attributes A related thing to consider is whether the attributes returned by NFS V3's GETATTR (fattr3) should be handled differently. If fattr3 is UNIX-centric, then perhaps servers should be allowed to not return values for some fattr3 attributes. On the other hand, some fattr3 attributes are critical to the operation of some clients. UNIX clients for instance depend on a fileid being available. If we have extended attributes, does it make sense to always return attributes on NFS operations as NFS V3 does? The purpose of doing this in NFS V3 was to reduce round trips and save network bandwidth. If a client still has to follow up a LOOKUP operation with an GET_XATTR operation, then nothing has been saved. A different approach might be to let clients use the COMPOUND operation to decide with attributes, basic and/or extended to return. Things not to consider ====================== Cache coherency --------------- Competing file sharing systems implemented cache coherency for performance reasons. NFS Version 3 solved the write throughput bottleneck. The notion that cache coherency provides better semantics is a red herring. Without good locking, data integrity suffers with or without cache coherency. In face of server, client, or network crash, every known cache coherent system will relax coherency constraints. This is also true for cache coherent file sharing systems that add support for disconnected operation. Things to consider but not part of the Protocol =============================================== Security -------- Keith Moore has stated that a "standard Internet File System needs a flexible authentication scheme which allows all of these: a. individual remote users need to be able to authenticate themselves as users of a file server (whether this maps to a particular UID on the server is an implementation issue) b. user domains (i.e. named collections of users) need to be able to authenticate themselves, on behalf of their users, to a file server. If the file server accepts the authentication, it extends trust to the entire collection of users. obviously, requests still need to be authenticated and to include the client user's identity, but how (or whether) these are mapped onto server UIDs is an implementation issue. c. anonymous access is very handy, especially if the protocol is more efficient than http." With respect a., there is no issue, because today the RPC layer will do the authentication, and as Keith notes, server implementations then map the user to a uid. With respect to b., one can argue that this is the province of the security system that the administrator decides to export his file systems with. Kerberos V5 does exactly what Keith describes. A user in realm X authenticates himself to the local KDC, and the KDC in in realm X authenticates itself to the KDC in realm Y, thereby transitively authenticating the user in realm X to a server in realm Y. With respect to c., there is no issue. NFS implementations have been providing anonymous access for sometime now. Keith has stated that authentication security "must be usable in several scenarios: a. between lonesome cowboys scattered at random on the 'net (perhaps PGP-style mutually-signed public keys?) b. within a small workgroup c. between small workgroups (perhaps with symmetric keys?) d. within a large organization which can impose an authentication certificate hierarchy" Kerberos V5 underneath GSS-API underneath the Internet Draft for RPCSEC_GSS will solve scenario's b and c, and perhaps (with public key extensions such as those proposed in the CAT-IETF wg) d. SPKM/GSS-API/RPCSEC_GSS will also solve d. To my knowledge, there is no GSS-API mechanism that provides for scenario a, though it is perhaps a small matter of programming and standardization work to do a PGP/GSS_API mechanism. Keith also states authentications security should have the following attributes: "must be strong enough that it's infeasible to defeat the crypto physical or other compromise of a system should not reveal keys that can be used to compromise other systems. must be extensible - so we can add new algorithms etc. as old ones are found to be breakable. must thwart replay attacks." The first one is largely a function of GSS-API security mechanism. Work at the CAT wg is in progress to add triple DES encryption and SHA integrity to Kerberos V5. Of course, by the time that work is done, 3DES/SHA might be found to be weak. The point being that the definition of strong crypto is a fast moving target. With respect to the second one, if one buys into a layered security model (GSS-API/RPCSEC_GSS/NFS), then because multiple applications will be using GSS-API, there will always be a potential for transitive compromise. The administrators can solve this by requiring different sets of keys for each network service (NFS, ftp, etc.) that is being used (at the expense of user friendliness). Security mechanisms under GSS-API should though use unique session keys so that if they are compromised, the session keys are useless to compromise other sessions, whether they are for NFS or not. With respect to the third attribute, GSS-API/RPCSEC_GSS has this. With respect to the fourth attribute, RPCSEC_GSS has replay protection. On privacy/confidentiality, Keith says that NFS "should support it. should be able to leave it off, also." RPCSEC_GSS supports authentication with optional integrity and privacy. Acknowledgements ================ Brent Callaghan, Jon Dreyer, Kirk McKusick, Keith Moore for generating ideas that contributed to this outline. From nfs4-wg-request Tue Dec 3 11:49:08 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08576; Tue, 3 Dec 96 11:49:09 PST Return-Path: Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08572; Tue, 3 Dec 96 11:49:08 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA00910; Tue, 3 Dec 1996 11:41:37 -0800 Received: from weaver-gw.netapp.com (weaver-gw.netapp.com [198.95.224.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA12041 for ; Tue, 3 Dec 1996 11:41:36 -0800 Received: from netapp.com ([192.9.200.1]) by weaver.netapp.com with SMTP id <15868-3044>; Tue, 3 Dec 1996 11:42:10 -0000 Received: from tooting.netapp.com by netapp.com (4.1/SMI-4.1) id AA23157; Tue, 3 Dec 96 11:41:33 PST Received: by tooting.netapp.com (SMI-8.6/SMI-SVR4) id LAA20305; Tue, 3 Dec 1996 11:41:02 -0800 From: beepy@netapp.com (Brian Pawlowski) Message-Id: <199612031941.LAA20305@tooting.netapp.com> Subject: Re: Kick-off discussion In-Reply-To: <199612021906.LAA12635@jurassic.eng.sun.com> from "Michael R. Eisler" at "Dec 2, 96 11:06:57 am" To: michael.eisler@Eng (Michael R. Eisler) Date: Tue, 3 Dec 1996 11:41:02 -0800 (PST) Cc: nfs4-wg@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME++ PL24 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1261 Lines: 26 The Opportunistic Locking support in CIFS (the protocol formerly known as SMB) has the flavor of a cache consistency protocol, which Mike later on put in a "not to be considered" category (or some such). The principal win of OpLocks is to allow aggressive caching by the client (seemingly to the extent of writes that can live and die in client cache -- similar to Sprite file system at Berkeley?) Anyway, I kinda view OpLocks as a cache consistency issue rather than a "locking" issue, because it entails cache coherency and flush backs and server-based management of multiple clients sharing data in a rather more generalized way than a simple YES/NO access defined by "normal" locking. (But perhaps you didn't want comments now:-) > Opportunistic locking > --------------------- > This is an idea borrowed from SMB. Locking can be made > efficient if the client always tries to lock an entire file, > even if the application is locking just a part of the file. If > the client gets the lock, then it can cache the file at will. > If someone else later wants to lock the file, the server tells > the first client that it must case "opportunistic locking", and > lock the file using record locking (after flushing any dirty > bits in its cache). From nfs4-wg-request Tue Dec 3 12:30:08 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08615; Tue, 3 Dec 96 12:30:09 PST Return-Path: Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08611; Tue, 3 Dec 96 12:30:08 PST Received: from teal by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA12860; Tue, 3 Dec 1996 12:22:33 -0800 Date: Tue, 3 Dec 1996 12:22:07 -0800 (PST) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: Kick-off discussion To: Brian Pawlowski Cc: nfs4-wg@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199612031941.LAA20305@tooting.netapp.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO Content-Length: 3506 Lines: 68 > From: beepy@netapp.com (Brian Pawlowski) > The Opportunistic Locking support in CIFS (the protocol formerly known > as SMB) has the flavor of a cache consistency protocol, which Mike > later on put in a "not to be considered" category (or some such). It may have a flavor of cache consistency but it isn't the general cache consistency protocol that lets one relax close to open semantics or causes processes with no record locks to hang in read or write system calls waiting for paritioned or dead clients to yield cache conflicting tokens. Cache consistency protocols that let one relax c-to-o are full of weird recovery scenarios. This is the problem with data cache tokens. On the other hand with locking tokens, there is no issue with breaking close-to-open semantics ... if the file is closed the lock has to be given up. The only clients than hang waiting for conflict lock tokens are those processes that invoke locking system calls. And the beauty of the recovery scenarios is that the situation of a process hanging in fcntl() waiting for a lock that isn't forthcoming because the lock owner's machine is dead or parititioned is little different than the situation of lock owner simply deciding to never release the lock. Unlike data cache tokens, one cannot normally force a process to give up it's lock token. Unless of course, the server decides that the holding client is dead. If a process has an op-lock, and another process on another client tries to write the file without acquiring a lock, then I would not expect the second ^^^^^^^^^^^^^^^^^^^^^^^^^^^ client block the write waiting for the first client to give up the op-lock ... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ why should it .. locking is advisory not mandatory in this case. Perhaps SMB does otherwise, but that isn't my vision of how it should work in NFS V4. This may be the source of our mutual misunderstanding. Of course all bets are off with mandatory locking, but even so, the file owner decided to enable mandatory locking by turning on the mandlock attribute (apologies if this is too UNIX'y ... I've never been clear about exactly how PC mand locks work) so the file owner pays the price of forcing an effectively data cache consistency model on his applications. > The principal win of OpLocks is to allow aggressive caching by the > client (seemingly to the extent of writes that can live and die in > client cache -- similar to Sprite file system at Berkeley?) > Anyway, I kinda view OpLocks as a cache consistency issue rather than a > "locking" issue, because it entails cache coherency and flush backs and > server-based management of multiple clients sharing data in a rather > more generalized way than a simple YES/NO access defined by "normal" > locking. Are you saying we should either not do NFS OpLocks, or if we do, implement a general cache consistency protocol? > (But perhaps you didn't want comments now:-) > > > Opportunistic locking > > --------------------- > > This is an idea borrowed from SMB. Locking can be made > > efficient if the client always tries to lock an entire file, > > even if the application is locking just a part of the file. If > > the client gets the lock, then it can cache the file at will. > > If someone else later wants to lock the file, the server tells > > the first client that it must case "opportunistic locking", and ^^^^ cease > > lock the file using record locking (after flushing any dirty > > bits in its cache). From nfs4-wg-request Tue Dec 3 13:07:56 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08652; Tue, 3 Dec 96 13:07:58 PST Return-Path: Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08648; Tue, 3 Dec 96 13:07:56 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA17556; Tue, 3 Dec 1996 13:00:24 -0800 Received: from weaver-gw.netapp.com (weaver-gw.netapp.com [198.95.224.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA11573 for ; Tue, 3 Dec 1996 13:00:21 -0800 Received: from netapp.com ([192.9.200.1]) by weaver.netapp.com with SMTP id <15932-3044>; Tue, 3 Dec 1996 13:00:57 -0000 Received: from tooting.netapp.com by netapp.com (4.1/SMI-4.1) id AA01523; Tue, 3 Dec 96 13:00:24 PST Received: by tooting.netapp.com (SMI-8.6/SMI-SVR4) id MAA21194; Tue, 3 Dec 1996 12:59:54 -0800 From: beepy@netapp.com (Brian Pawlowski) Message-Id: <199612032059.MAA21194@tooting.netapp.com> Subject: Re: Kick-off discussion In-Reply-To: <9612032023.AA27368@netapp.com> from Mike Eisler at "Dec 3, 96 12:22:07 pm" To: mre@pacific.eng.sun.com Date: Tue, 3 Dec 1996 12:59:54 -0800 (PST) Cc: beepy@netapp.com, nfs4-wg@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME++ PL24 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Content-Length: 574 Lines: 12 > Are you saying we should either not do NFS OpLocks, or if we do, implement > a general cache consistency protocol? Far be it from me to say anything... But yeah, in a nutshell I wonder if pursuit of OpLocks might be complicated enough to warrant consideration of a generalized mechanism for consistency. At the very least, I feel consideration of OpLocks is a complication, and the statement in the stuff sent out about avoiding Cache Consistency (to reduce complexity?) is diluted by slipping in OpLocks... I'm not exactly a cache consistency proponent, by the way... From nfs4-wg-request Tue Dec 3 13:15:16 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08667; Tue, 3 Dec 96 13:15:17 PST Return-Path: Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08663; Tue, 3 Dec 96 13:15:16 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA19127; Tue, 3 Dec 1996 13:07:45 -0800 Received: from weaver-gw.netapp.com (weaver-gw.netapp.com [198.95.224.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA14187 for ; Tue, 3 Dec 1996 13:07:43 -0800 Received: from netapp.com ([192.9.200.1]) by weaver.netapp.com with SMTP id <15925-3044>; Tue, 3 Dec 1996 13:08:13 -0000 Received: from tooting.netapp.com by netapp.com (4.1/SMI-4.1) id AA02146; Tue, 3 Dec 96 13:07:40 PST Received: by tooting.netapp.com (SMI-8.6/SMI-SVR4) id NAA21319; Tue, 3 Dec 1996 13:07:11 -0800 From: guy@netapp.com (Guy Harris) Message-Id: <199612032107.NAA21319@tooting.netapp.com> Subject: Re: Kick-off discussion In-Reply-To: <9612032035.AA28382@netapp.com> from Mike Eisler at "Dec 3, 96 12:22:07 pm" To: mre@pacific.eng.sun.com Date: Tue, 3 Dec 1996 13:07:11 -0800 (PST) Cc: beepy@netapp.com, nfs4-wg@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME++ PL28 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Content-Length: 5764 Lines: 110 > > From: beepy@netapp.com (Brian Pawlowski) > > The Opportunistic Locking support in CIFS (the protocol formerly known > > as SMB) has the flavor of a cache consistency protocol, which Mike > > later on put in a "not to be considered" category (or some such). > > It may have a flavor of cache consistency but it isn't the general cache > consistency protocol that lets one relax close to open semantics or causes > processes with no record locks to hang in read or write system calls waiting > for paritioned or dead clients to yield cache conflicting tokens. Cache > consistency protocols that let one relax c-to-o are full of weird recovery > scenarios. This is the problem with data cache tokens. > > On the other hand with locking tokens, there is no issue with breaking > close-to-open semantics ... if the file is closed the lock has to be given up. > The only clients than hang waiting for conflict lock tokens are those > processes that invoke locking system calls. What you get, in effect, when you have been granted an opportunistic "lock" is not a "locking token" - opportunistic "locks" affect even clients that do no byte-range locking nor opens that deny read or write access. There are three kinds of opportunistic "locks". The first kind is an "exclusive" op"lock". If a client machine is granted an exclusive op"lock", then it may keep cached data for that file, and needn't send byte-range locking requests to the server. However, if another client machine opens the file, the server sends to the first client, in the process of doing the open, a "your op'lock' has been broken" message; the second client machine's open blocks until the first client sends back to the server a message saying that it's sent all dirty buffers for that file back to the server and has sent to the server message to gain all byte-range locks that it had been keeping for the file. This means that the second client's open can hang for a while if the first client is dead or unreachable - it'll probably hang until the client responds or until the server declares the client dead, breaks its connection to that client, and closes all the files the client has open. Exclusive op"locks" don't remove the need for close-to-open consistency - the client cannot assume that the file won't be changed by other machines after the file was closed, and thus cannot keep cached data for that file, and the client must write back all dirty buffers for the file before closing it, as, once it's closed, it can't write back to the file. (Well, maybe if somebody else had it open, it could - *if* that open permitted writes.) The second kind of op"lock" is a batch op"lock". If a client is granted a batch op"lock", it may not only cache data for the file - it may also cache, in effect, the open file handle it got back in the reply to the open. If another client machine opens the file, or attempts to rename or delete it, the first client is again told that its op"lock" has been broken; the client must now *close* the file, after sending back dirty data and locks, and the second client's open/rename/delete doesn't complete until the first client's close is received by the server. This arguably means that close-to-open consistency is *not* maintained. The third kind of op"lock" is a "level II" op"lock". A level II op"lock" allows multiple client machines to have the file open for reading; it's not broken until a client attempts to open the file for writing. A client that has an exclusive op"lock" may have it degraded to a level II op"lock" if the first client had the file open for reading and the second client is also opening it only for reading. > And the beauty of the recovery > scenarios is that the situation of a process hanging in fcntl() waiting for a > lock that isn't forthcoming because the lock owner's machine is dead or > parititioned is little different than the situation of lock owner simply > deciding to never release the lock. Unlike data cache tokens, one cannot > normally force a process to give up it's lock token. Unless of course, the > server decides that the holding client is dead. > > If a process has an op-lock, and another process on another client tries to > write the file without acquiring a lock, then I would not expect the second > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > client block the write waiting for the first client to give up the op-lock ... > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > why should it .. locking is advisory not mandatory in this case. Perhaps SMB > does otherwise, but that isn't my vision of how it should work in NFS V4. This > may be the source of our mutual misunderstanding. As indicated, the only connection between SMB op"locks" and byte-range locks is that a client holding an op"lock" needn't send byte-range lock requests to the server. The rough equivalent in SMBland of the scenario you describe is that client A opened a file and was granted an op"lock", and client B attempted to open the file for writing. In SMBland, client B's open *WOULD* block waiting for the first client to give up its op"lock". I.e., as I infer from your description, the NFS op"locks" being described here are, apparently, significantly different from SMB op"locks", in that they are advisory. SMB op"locks" are mandatory. In addition, I also infer from your description that a client would ask for an NFS op"lock" only if it's going to use record locking on the file. Summary: SMB op"locks" NFS V4 op"locks" mandatory advisory unconnected with byte-range obtained only when byte-range locking locks will be done clients must not cache data clients not doing byte-range locking unless they hold an are free to cache data even if they appropriate op"lock" hold no op"lock" From nfs4-wg-request Tue Dec 3 18:21:00 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09029; Tue, 3 Dec 96 18:21:01 PST Return-Path: Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09025; Tue, 3 Dec 96 18:21:00 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA09124; Tue, 3 Dec 1996 18:13:29 -0800 Received: from weaver-gw.netapp.com (weaver-gw.netapp.com [198.95.224.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id SAA17972 for ; Tue, 3 Dec 1996 18:13:29 -0800 Received: from netapp.com ([192.9.200.1]) by weaver.netapp.com with SMTP id <15867-3042>; Tue, 3 Dec 1996 18:14:06 -0000 Received: from tooting.netapp.com by netapp.com (4.1/SMI-4.1) id AA04752; Tue, 3 Dec 96 18:13:32 PST Received: by tooting.netapp.com (SMI-8.6/SMI-SVR4) id SAA20703; Tue, 3 Dec 1996 18:13:03 -0800 From: guy@netapp.com (Guy Harris) Message-Id: <199612040213.SAA20703@tooting.netapp.com> Subject: Re: Kick-off discussion In-Reply-To: <199612021906.LAA12635@jurassic.eng.sun.com> from "Michael R. Eisler" at "Dec 2, 96 11:06:57 am" To: michael.eisler@Eng (Michael R. Eisler) Date: Tue, 3 Dec 1996 18:13:02 -0800 (PST) Cc: nfs4-wg@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME++ PL28 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1026 Lines: 23 > COPY procedure > -------------- > It is believed that some operating systems, such as those on > PCs, includes a file COPY interface, and that this interfaces > is frequently used. If so, a COPY procedure should be added. Any idea what particular OSes those are? Some PC operating system don't, as far as I know, e.g. Solaris 2.x, Linux, and FreeBSD :-) More important, I don't remember seeing one in an obvious place in the Win32 API specification, either. There might be one in DOS or Win16, as there *is* a "copy" operation in SMB. I vaguely remember hearing that Win32 clients might start using the "copy" operation in the future, but don't know whether Yet Another Procedure will be added to the Win32 API or not. > Minor Versioning > ================ If the only thing one can do in version X.Y+1 of NFS is to add new procedures, is there a reason why one can't just have clients attempt to use a new procedure and, if told "that procedure doesn't exist", fall back on whatever it would do in version X.Y? From nfs4-wg-request Tue Dec 3 18:39:50 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09066; Tue, 3 Dec 96 18:39:51 PST Return-Path: Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09062; Tue, 3 Dec 96 18:39:50 PST Received: from teal by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA10858; Tue, 3 Dec 1996 18:32:18 -0800 Date: Tue, 3 Dec 1996 18:31:53 -0800 (PST) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: Kick-off discussion To: Guy Harris Cc: nfs4-wg@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199612040213.SAA20703@tooting.netapp.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO Content-Length: 1399 Lines: 40 > > COPY procedure > > -------------- > > It is believed that some operating systems, such as those on > > PCs, includes a file COPY interface, and that this interfaces > > is frequently used. If so, a COPY procedure should be added. > > Any idea what particular OSes those are? Some PC operating system I'm rechecking with my source on this. > > > Minor Versioning > > ================ > > If the only thing one can do in version X.Y+1 of NFS is to add new Well one might be able to modify procedures in backwards compatible ways, say by adding a flag bit, or adding (or deleting) an attribute in an extended attribute manipulation procedure. > procedures, is there a reason why one can't just have clients attempt to > use a new procedure and, if told "that procedure doesn't exist", fall > back on whatever it would do in version X.Y? People are already trying this stunt to add their own custom proprietary NFS ops to NFS V2 and NFS V3. Having an explicit minor versioning scheme would tend to discourage that practice. Having the NFS server explicitly report its minor version w/ a ops vector is a fast way for the client to figure out what operations it can use, and what semantics for each supported operation. Minor versioning is new territory, and I'd like to see something as complete as possible, lest we find that we forgot something making the feature useless. -mre From nfs4-wg-request Wed Dec 4 11:52:29 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09777; Wed, 4 Dec 96 11:52:30 PST Return-Path: Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09773; Wed, 4 Dec 96 11:52:29 PST Received: from East.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA14640; Wed, 4 Dec 1996 11:44:56 -0800 Received: from pdp8.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id OAA04079; Wed, 4 Dec 1996 14:44:53 -0500 Received: from pdp8 by pdp8.East.Sun.COM (SMI-8.6/SMI-SVR4) id OAA24999; Wed, 4 Dec 1996 14:43:19 -0500 Date: Wed, 4 Dec 1996 14:43:19 -0500 (EST) From: Jon Dreyer Reply-To: Jon Dreyer Subject: Re: Kick-off discussion To: "Michael R. Eisler" , Guy Harris Cc: nfs4-wg@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: c0eRhIrHV+cJRuPz6V8fdQ== Status: RO Content-Length: 1853 Lines: 42 > From: guy@netapp.com (Guy Harris) > > > COPY procedure > > -------------- > > It is believed that some operating systems, such as those on > > PCs, includes a file COPY interface, and that this interfaces > > is frequently used. If so, a COPY procedure should be added. > > Any idea what particular OSes those are? Some PC operating system > don't, as far as I know, e.g. Solaris 2.x, Linux, and FreeBSD :-) > > More important, I don't remember seeing one in an obvious place in the > Win32 API specification, either. There might be one in DOS or Win16, as > there *is* a "copy" operation in SMB. I vaguely remember hearing that > Win32 clients might start using the "copy" operation in the future, but > don't know whether Yet Another Procedure will be added to the Win32 API > or not. There is no (documented) copy procedure at the win95 ifsmgr layer, and I'm told there's none in NT's equivalent either. In any case, we haven't implemented copy procedures and it hasn't caused us any trouble (yet). Under dos, lanman and netware each have different versions of remote copy. You can see the lanman version at http://www.delorie.com/djgpp/doc/rbinter/id/64/27.html (presumably this uses the smb copy operation mentioned above; it has cute semantics like ascii/binary copies) or the netware version at http://www.delorie.com/djgpp/doc/rbinter/id/67/36.html . We have never implemented these, and I've never heard a complaint about this. Presumably apps have been written not to depend on them. I don't think it's a big deal. One nice thing about remote copy (besides performance) is that there's no mapping of attributes: you can preserve attributes that are locally meaningful to the server or nfs attrs that are not preserved by the client implementation. But if apps don't generally use this call, I don't see the point. Jon From nfs4-wg-request Thu Dec 5 13:32:21 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01414; Thu, 5 Dec 96 13:32:22 PST Return-Path: Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01410; Thu, 5 Dec 96 13:32:21 PST Received: from East.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA16437; Thu, 5 Dec 1996 13:24:45 -0800 Received: from pdp8.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id QAA01814; Thu, 5 Dec 1996 16:24:44 -0500 Received: from pdp8 by pdp8.East.Sun.COM (SMI-8.6/SMI-SVR4) id QAA26390; Thu, 5 Dec 1996 16:23:24 -0500 Date: Thu, 5 Dec 1996 16:23:24 -0500 (EST) From: Jon Dreyer Reply-To: Jon Dreyer Subject: Re: Kick-off discussion (Fwd) (Fwd) To: Mike Eisler , nfs4-wg@sunroof.eng.sun.com Cc: jdreyer@pdp8.East.Sun.COM Message-Id: Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: he2O2TolG0oK2ZKlA6TCqw== Status: RO Content-Length: 1700 Lines: 32 > From: Mike Eisler > > Ok, so based on what Gy and Brian are saying, SMB opportunistic > locks effectively place a mandatory lock semantic on files without > the a mand lock bit set. Given that, does it help the PC to > provide a weaker form that I've proposed which would not affect > the I/O of processes that didn't lock the file? Jon? Mark? > > SMB-style op-locks seem like a bad idea since they amount to a large > hunk of cache coherency which I oppose (pending a strong argument from > anyone who can convince me otherwise). If eisler-style op-locks don't > benefit the PC, then I suggest we (SMI) withdraw the idea. Seems to me a simple Eisler-style advisory oplock kind of thing can benefit anyone using byterange locking, not just the pc, because a client only incurs a significant locking expense if it's competing with another client. That would mean you could always assume you were doing network locking, rather than asking the user to make a manual decision. I'd like to emphasize one point. As far as I know, oplocks do not provide any functionality to pcs, nor is there a way for an application to use them explicitly. Rather, it's a behind-the-scenes performance boost. Seems like whatever we come up with for locking could make use of this idea, but within the context of advisory locking, without adding too much complexity. P.S. I lost the msg describing Eisler-style oplocks, but I think I'm staying close to that concept here. Please disabuse me if necessary. P.P.S I have somehow avoided getting a good understanding of what the cache coherency, close-open, etc. arguments are. I'd appreciate a pointer to a reference or two. From nfs4-wg-request Fri Dec 6 07:44:14 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02540; Fri, 6 Dec 96 07:44:16 PST Return-Path: Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02536; Fri, 6 Dec 96 07:44:14 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA06391; Fri, 6 Dec 1996 07:36:39 -0800 From: boris@ftp.com Received: from ftp.com (ftp.com [128.127.2.122]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA16627 for ; Fri, 6 Dec 1996 07:36:38 -0800 Received: from ftp.com by ftp.com ; Fri, 6 Dec 1996 10:36:33 -0500 Received: from mailserv-2high.ftp.com by ftp.com ; Fri, 6 Dec 1996 10:36:33 -0500 Received: from ntbook by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id KAA08860; Fri, 6 Dec 1996 10:36:32 -0500 Date: Fri, 6 Dec 96 08:54:56 PST Subject: RE: Kick-off discussion To: nfs4-wg@sunroof.eng.sun.com, "Michael R. Eisler" X-Mailer: B_Mailer 0-0, KISS- .... X-Priority: 3 (Normal) Message-Id: 961206103213.boris@ntbook> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT Status: RO Content-Length: 6187 Lines: 144 Hello, Sorry I could not reply right away. --- On Mon, 2 Dec 1996 11:06:57 -0800 "Michael R. Eisler" wrote: > query for exported file systems > ------------------------------- > > It is proposed that the MOUNT protocol not be used for boot > strapping NFS Version 4 client/server sessions, and in its > place, a new procedure, SHAREINFO, be added. The SHAREINFO > procedure would return the list of exported file systems (by > path name). Why not just a READDIR? After all exports are just the directory files. As the starting point in this READDIR (instead of the Directory File Handle) we can use the mechanism proposed in the new LOOKUP. > security flavor negotiation > --------------------------- It would be great to create a generic security model that is based on generic (non uid/gid) Identity, generic Object (server, file, etc.), and generic Rights. > compound operations > ------------------ > Two of such compound operations that are highly useful for NT and W95 (as well as for VMS) based clients are combinations of LOOKUP+SHARE and UNSHARE+LOCK OFF+COMMIT (name: OPEN and CLOSE). >Non-UNIX systems >================ > > [ Note this section has a PC-centric slant ] > > Export inheritance > ------------------ > The NFS protocol is specified to not let a NFS client cross > mount points. This is so the NFS client does not get confused > about the identity of files in the even two files on two > different server file systems share the same file id (inode #). > > This semantic is not desired by some clients, such as PC desk tops. > The proposal, as described previously, is to make > mount point crossing optional. The main advantage of NFS (compared to SMB) is its heterogeneous nature. Things like 'inode #' that can confuse clients and 'mount points' directly contradict this nature. About crossing mount point: if shares are treated as simple files growing from a known root, the problem of crossing mount points goes away. Let say we have two exports on the system: adsk:[dir1.dir2] (/adsk/dir1/dir2) bdsk:[foo.goo] (/bdsk/foo/goo) the request adsk:[dir1.dir2]\..\bdsk:[foo.goo] (/adsk/dir1/dir2\..\/bdsk/foo/goo) should bring us correctly into bdsk:[foo.goo] (/bdsk/foo/goo). I do not think that this approach is harmful for URLs. URL editors just assume that they have to share the highest point of relative references - and they just shall do this. > > COPY procedure > -------------- > It is believed that some operating systems, such as those on > PCs, includes a file COPY interface, and that this interfaces > is frequently used. If so, a COPY procedure should be added. > NT and W95 file systems do not include this operation. > Extended Attributes > ------------------- > A "hidden" and "archive" bit would be useful to PCs using NFS. Lets call this section Basic Attributes to be distinguished from the Extended Attributes that you described later. This will be consistent with the terminology of some Operating Systems (NT, VMS, etc.). > > Case Sensitivity > ---------------- Thank you! This is the second big performance item (after multi-component lookups)! > > Opportunistic locking > --------------------- > This is an idea borrowed from SMB. Locking can be made > efficient if the client always tries to lock an entire file, > even if the application is locking just a part of the file. If > the client gets the lock, then it can cache the file at will. > If someone else later wants to lock the file, the server tells > the first client that it must case "opportunistic locking", and > lock the file using record locking (after flushing any dirty > bits in its cache). > I understand OpLocks differently. They are not an attempt to enhance locking by expanding the region. Actually have very little to do with regular lock at all. They rather have something to do with WRITEs. They are associated with the byte range (we almost never want to cache entire file, or even if we do, this is a specific case of the byte range). OpLocks can be shared or exclusive. About a week ago I wrote some notes what we (FTP) want to see in the NFS-4. Following is the section describing shared OpLock behavior. (I prefer to call them Client Locks - no to be confused with SMB OpLocks). --- On Tue, 26 Nov 96 14:36:11 PST boris@ftp.com wrote: 7 Client Locks We need to add the ability for a client to inform a server that it is caching some ranges of files. This can be done using a mechanism similar to Blocked Locks. Clients should be able to issue special 'Client Locks'. The Client Lock means that the client is caching the file region specified in this lock. If no user locks are associated with the region, the requested Client Lock should be granted. Several different clients can issue Client Locks for overlapping file regions - these locks should be granted since they do not conflict. If part of the region that was requested in the Client Lock request is already locked via another client's regular NLM Lock, the Client Lock should be denied. Any attempt to write into the regions protected by Client Locks, delete files, or even get a regular NLM lock for any part of the region should trigger a Client Lock Broken message from the server to the client. If the Client receives a Client Lock Broken message, the Client should discard the cache region specified in the message. This semantics can be expanded to support not only read caching, but write caching as well. One other performance related wish that I included in my notes and could not find in your proposal is: 7 Wild-carded name parameters for READDIRs I'd like to expand READDIR(PLUS) syntax to allow the specification of search targets that can include wildcard characters. This should significantly reduce the amount of data we send on READDIRs. From nfs4-wg-request Fri Dec 6 20:16:28 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03723; Fri, 6 Dec 96 20:16:29 PST Return-Path: Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03719; Fri, 6 Dec 96 20:16:28 PST Received: from terra.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA12565; Fri, 6 Dec 1996 20:08:53 -0800 Received: by terra.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA10870; Fri, 6 Dec 1996 20:05:04 -0800 Date: Fri, 6 Dec 1996 20:05:04 -0800 From: brent@jurassic (Brent Callaghan) Message-Id: <199612070405.UAA10870@terra.eng.sun.com> To: guy@netapp.com Subject: Re: Minor versioning Cc: nfs4-wg@sunroof X-Sun-Charset: US-ASCII Status: RO Content-Length: 388 Lines: 15 Minor versioning also has a good marketing rationale. Motivation for vendors to keep their implementation up-to-date. If company X advertises NFS V4.2 and company Y is only at V4.1 then company Y is motivated to support V4.2. Of course, Joe customer doesn't care what's *in* version V4.2, but the bigger number means "better" right ? :-) Brent ----- Begin Included Message ----- From mre@pacific.eng.sun.com Tue Dec 3 18:32:43 1996 Subject: Re: Kick-off discussion To: Guy Harris Cc: nfs4-wg@sunroof.eng.sun.com Mime-Version: 1.0 Status: RO Content-Length: 1081 Lines: 34 > > Minor Versioning > > ================ > > If the only thing one can do in version X.Y+1 of NFS is to add new Well one might be able to modify procedures in backwards compatible ways, say by adding a flag bit, or adding (or deleting) an attribute in an extended attribute manipulation procedure. > procedures, is there a reason why one can't just have clients attempt to > use a new procedure and, if told "that procedure doesn't exist", fall > back on whatever it would do in version X.Y? People are already trying this stunt to add their own custom proprietary NFS ops to NFS V2 and NFS V3. Having an explicit minor versioning scheme would tend to discourage that practice. Having the NFS server explicitly report its minor version w/ a ops vector is a fast way for the client to figure out what operations it can use, and what semantics for each supported operation. Minor versioning is new territory, and I'd like to see something as complete as possible, lest we find that we forgot something making the feature useless. -mre ----- End Included Message ----- From nfs4-wg-request Sat Dec 7 04:59:09 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04121; Sat, 7 Dec 96 04:59:10 PST Return-Path: Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04117; Sat, 7 Dec 96 04:59:09 PST Received: from teal by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA23037; Sat, 7 Dec 1996 04:51:31 -0800 Date: Sat, 7 Dec 1996 04:51:02 -0800 (PST) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: Kick-off discussion (Fwd) (Fwd) To: Jon Dreyer Cc: nfs4-wg@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO Content-Length: 2274 Lines: 50 > > From: Mike Eisler > > > > Ok, so based on what Gy and Brian are saying, SMB opportunistic > > locks effectively place a mandatory lock semantic on files without > > the a mand lock bit set. Given that, does it help the PC to > > provide a weaker form that I've proposed which would not affect > > the I/O of processes that didn't lock the file? Jon? Mark? > > > > SMB-style op-locks seem like a bad idea since they amount to a large > > hunk of cache coherency which I oppose (pending a strong argument from > > anyone who can convince me otherwise). If eisler-style op-locks don't > > benefit the PC, then I suggest we (SMI) withdraw the idea. > > Seems to me a simple Eisler-style advisory oplock kind of thing can benefit > anyone using byterange locking, not just the pc, because a client only > incurs a significant locking expense if it's competing with another client. > That would mean you could always assume you were doing network locking, > rather than asking the user to make a manual decision. > > I'd like to emphasize one point. As far as I know, oplocks do not provide > any functionality to pcs, nor is there a way for an application to use them > explicitly. Rather, it's a behind-the-scenes performance boost. Seems > like whatever we come up with for locking could make use of this idea, but > within the context of advisory locking, without adding too much complexity. Ok, so it sounds like my notion of "op-locks" would be useful. I will follow up with a precise definition of what I intend and avoid the use of terms "op-locks" and "opportunistic locks". > P.S. I lost the msg describing Eisler-style oplocks, but I think I'm > staying close to that concept here. Please disabuse me if necessary. > > P.P.S I have somehow avoided getting a good understanding of what the cache > coherency, close-open, etc. arguments are. I'd appreciate a pointer to a > reference or two. Jeff Mogul's Spritely NFS paper: http://www.research.digital.com/wrl/publications/abstracts/93.2.html it's a hefty but extremely well written paper. Also, you might read: http://weeble.lut.ac.uk/lists/http-caching/0045.html Jeff argues that a caching scheme with callbacks may not be advisable for http proxies. -mre From nfs4-wg-request Sat Dec 7 05:01:28 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04128; Sat, 7 Dec 96 05:01:29 PST Return-Path: Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04124; Sat, 7 Dec 96 05:01:28 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA20921; Sat, 7 Dec 1996 04:53:50 -0800 From: boris@ftp.com Received: from ftp.com (ftp.com [128.127.2.122]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA18038 for ; Sat, 7 Dec 1996 04:53:51 -0800 Received: from ftp.com by ftp.com ; Sat, 7 Dec 1996 07:53:47 -0500 Received: from mailserv-2high.ftp.com by ftp.com ; Sat, 7 Dec 1996 07:53:47 -0500 Received: from ntbook by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id HAA01424; Sat, 7 Dec 1996 07:53:46 -0500 Date: Sat, 7 Dec 96 07:44:44 PST Subject: Re: Minor versioning To: guy@netapp.com, Brent Callaghan Cc: nfs4-wg@sunroof.eng.sun.com X-Priority: 3 (Normal) X-Mailer: B_Mailer 0-0, KISS- .... Message-Id: 961207074910.boris@ntbook> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Content-Length: 2040 Lines: 67 From other point we do not want to find ourselves in the situation that exists in current SMB, where W3.11, W95, NT3.1, NT3.51, and NT4.0 have REAL problems talking to each other. Boris --- On Fri, 6 Dec 1996 20:05:04 -0800 Brent Callaghan wrote: > >Minor versioning also has a good marketing rationale. > >Motivation for vendors to keep their implementation up-to-date. > >If company X advertises NFS V4.2 and company Y is only at V4.1 >then company Y is motivated to support V4.2. > >Of course, Joe customer doesn't care what's *in* version V4.2, >but the bigger number means "better" right ? :-) > > Brent > > >----- Begin Included Message ----- > >>From mre@pacific.eng.sun.com Tue Dec 3 18:32:43 1996 >Subject: Re: Kick-off discussion >To: Guy Harris >Cc: nfs4-wg@sunroof.eng.sun.com >Mime-Version: 1.0 > >> > Minor Versioning >> > ================ >> >> If the only thing one can do in version X.Y+1 of NFS is to add new > >Well one might be able to modify procedures in backwards compatible ways, >say by adding a flag bit, or adding (or deleting) an attribute in >an extended attribute manipulation procedure. > >> procedures, is there a reason why one can't just have clients attempt to >> use a new procedure and, if told "that procedure doesn't exist", fall >> back on whatever it would do in version X.Y? > >People are already trying this stunt to add their own custom >proprietary NFS ops to NFS V2 and NFS V3. Having >an explicit minor versioning scheme would tend to discourage that >practice. > >Having the NFS server explicitly report its minor version w/ a ops vector is a >fast way for the client to figure out what operations it can use, and what >semantics for each supported operation. > >Minor versioning is new territory, and I'd like to see something as >complete as possible, lest we find that we forgot something making the feature >useless. > > -mre > > > > >----- End Included Message ----- > > > -----------------End of Original Message----------------- From nfs4-wg-request Sat Dec 7 05:08:10 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04135; Sat, 7 Dec 96 05:08:11 PST Return-Path: Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04131; Sat, 7 Dec 96 05:08:10 PST Received: from teal by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA23229; Sat, 7 Dec 1996 05:00:34 -0800 Date: Sat, 7 Dec 1996 05:00:07 -0800 (PST) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: Minor versioning To: boris@ftp.com Cc: nfs4-wg@sunroof.eng.sun.com In-Reply-To: "Your message with ID" 961207074910.boris@ntbook> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO Content-Length: 753 Lines: 24 That's why I proposed that version 4.x be a super set of 4.x-1. > From other point we do not want to find ourselves in the situation > that exists in current SMB, where W3.11, W95, NT3.1, NT3.51, and NT4.0 > have REAL problems talking to each other. > > Boris > > --- On Fri, 6 Dec 1996 20:05:04 -0800 Brent Callaghan > wrote: > > > > >Minor versioning also has a good marketing rationale. > > > >Motivation for vendors to keep their implementation up-to-date. > > > >If company X advertises NFS V4.2 and company Y is only at V4.1 > >then company Y is motivated to support V4.2. > > > >Of course, Joe customer doesn't care what's *in* version V4.2, > >but the bigger number means "better" right ? :-) > > > > Brent From nfs4-wg-request Sat Dec 7 05:48:15 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04151; Sat, 7 Dec 96 05:48:16 PST Return-Path: Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04147; Sat, 7 Dec 96 05:48:15 PST Received: from teal by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA23651; Sat, 7 Dec 1996 05:40:38 -0800 Date: Sat, 7 Dec 1996 05:40:10 -0800 (PST) From: Mike Eisler Reply-To: Mike Eisler Subject: RE: Kick-off discussion To: boris@ftp.com Cc: nfs4-wg@sunroof.eng.sun.com In-Reply-To: "Your message with ID" 961206103213.boris@ntbook> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO Content-Length: 7251 Lines: 165 boris@ftp.com wrote: > --- On Mon, 2 Dec 1996 11:06:57 -0800 "Michael R. Eisler" > wrote: > > > query for exported file systems > > ------------------------------- > > > > It is proposed that the MOUNT protocol not be used for boot > > strapping NFS Version 4 client/server sessions, and in its > > place, a new procedure, SHAREINFO, be added. The SHAREINFO > > procedure would return the list of exported file systems (by > > path name). > > Why not just a READDIR? After all exports are just the directory files. > As the starting point in this READDIR (instead of the Directory > File Handle) we can use the mechanism proposed in the new LOOKUP. What file handle do you use with this READDIR? Consider the case of an NFS server that exports dis-joint portions of its namespace: /export/home16 /pub If one just does a LOOKUP START_FROM_ROOT "/" from the client, my V4 server is going to refuse the access, because / isn't exported. And even if it did return a file handle, it won't permit a READDIR of "/" because "/" is unexported. There might be a a directory under "/" whose name I want to keep confidential ... say "/the_boris_files" :-) > > > security flavor negotiation > > --------------------------- > It would be great to create a generic security model that is > based on generic (non uid/gid) Identity, generic Object (server, > file, etc.), and generic Rights. I'm open to suggestions. It would also be great to have a model that doesn't introduce extra administration over and above the security mechanism being used in the RPC header. > >Non-UNIX systems > >================ > > > > [ Note this section has a PC-centric slant ] > > > > Export inheritance > > ------------------ > > The NFS protocol is specified to not let a NFS client cross > > mount points. This is so the NFS client does not get confused > > about the identity of files in the even two files on two > > different server file systems share the same file id (inode #). > > > > This semantic is not desired by some clients, such as PC desk tops. > > The proposal, as described previously, is to make > > mount point crossing optional. > > The main advantage of NFS (compared to SMB) is its heterogeneous nature. > Things like 'inode #' that can confuse clients and 'mount points' > directly contradict this nature. A client that doesn't grok fileid doesn't have to use it right? > About crossing mount point: if shares are treated as simple files growing > from a known root, the problem of crossing mount points goes away. I'm not sure how the UNIX problem of crossing mount points goes away. If f1 is under dir2 in your example, and f2 is under goo, and f1 and f2 have the same file id, a server that lets clients involuntarily cross mount points is going to cause problems. In any case, adding a bit to LOOKUP to control this gives each of us what we want, letting us at least be in violent agreement. > Let say we have two exports on the system: > adsk:[dir1.dir2] (/adsk/dir1/dir2) > bdsk:[foo.goo] (/bdsk/foo/goo) > the request adsk:[dir1.dir2]\..\bdsk:[foo.goo] > (/adsk/dir1/dir2\..\/bdsk/foo/goo) > should bring us correctly into bdsk:[foo.goo] (/bdsk/foo/goo). > I do not think that this approach is harmful for URLs. URL editors just > assume that they have to share the highest point of relative references - > and they just shall do this. Right ... WEB browsers don't care about mount crossing either. > > > > COPY procedure > > -------------- > > It is believed that some operating systems, such as those on > > PCs, includes a file COPY interface, and that this interfaces > > is frequently used. If so, a COPY procedure should be added. > > > NT and W95 file systems do not include this operation. We originally stuck this on the list because we saw it in CIFS thinking that there must be clients for it. Since, that is not the case consider it off the list. With minor versioning, we can add it later, if say NT 5.0 adds an API. > > Extended Attributes > > ------------------- > > A "hidden" and "archive" bit would be useful to PCs using NFS. > Lets call this section Basic Attributes to be distinguished from the > Extended Attributes that > you described later. This will be consistent with the terminology of > some Operating > Systems (NT, VMS, etc.). The WG needs to reach a consensus on what attributes should be basic and what should be extended, with a method for accomodating systems that don't support certain basic attributes. On the surface, I see nothing wrong with including "hidden" and "archive" in the basic set. > About a week ago I wrote some notes what we (FTP) want to see in the > NFS-4. Following is the section describing shared OpLock behavior. > (I prefer to call them Client Locks - no to be confused with SMB OpLocks). > > --- On Tue, 26 Nov 96 14:36:11 PST boris@ftp.com wrote: > > 7 Client Locks > We need to add the ability for a client to inform a server > that it is caching some ranges of files. This can be done > using a mechanism similar to Blocked Locks. Clients > should be able to issue special 'Client Locks'. > The Client Lock means that the client is caching the file > region specified in this lock. If no user locks are > associated with the region, the requested Client Lock > should be granted. Several different clients can issue > Client Locks for overlapping file regions - these locks ^^^^^^^^^^^^^^^^^^^^^^^^ > should be granted since they do not conflict. If part of ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This doesn't parse. Are these overlapping locks READ locks? > the region that was requested in the Client Lock request > is already locked via another client's regular > NLM Lock, the Client Lock should be denied. Any attempt > to write into the regions protected by Client Locks, delete > files, or even get a regular NLM lock for any part of the > region should trigger a Client Lock Broken message from the > server to the client. If the Client receives a Client Lock > Broken message, the Client should discard the cache region > specified in the message. Does the 2nd client that does the write have to block while the server is delivering the Client Lock Broken message to 1st client? How is this different from a full blown cache coherency (with all the recovery problems)? > One other performance related wish that I included in my notes and could > not find in your proposal is: > 7 Wild-carded name parameters for READDIRs > I'd like to expand READDIR(PLUS) syntax to allow > the specification of search targets that can include > wildcard characters. This should significantly reduce the > amount of data we send on READDIRs. I assume that there are platforms with system-level APIs that do this. For example, on the PC can one do something like: open("foo.???") I think if we include it, just as with case insensitivity, it has to be optional on the server. -mre From nfs4-wg-request Sun Dec 8 07:27:01 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04719; Sun, 8 Dec 96 07:27:02 PST Return-Path: Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04715; Sun, 8 Dec 96 07:27:01 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA25361; Sun, 8 Dec 1996 07:19:23 -0800 From: boris@ftp.com Received: from ftp.com (ftp.com [128.127.2.122]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA03468 for ; Sun, 8 Dec 1996 07:19:23 -0800 Received: from ftp.com by ftp.com ; Sun, 8 Dec 1996 10:19:20 -0500 Received: from mailserv-2high.ftp.com by ftp.com ; Sun, 8 Dec 1996 10:19:20 -0500 Received: from ntbook by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id KAA22682; Sun, 8 Dec 1996 10:19:16 -0500 Date: Sun, 8 Dec 96 04:33:24 PST Subject: RE: Kick-off discussion To: boris@ftp.com, Mike Eisler Cc: nfs4-wg@sunroof.eng.sun.com X-Priority: 3 (Normal) X-Mailer: B_Mailer 0-0, KISS- .... Message-Id: 961208043349.boris@ntbook> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO Content-Length: 7060 Lines: 164 Hello, --- On Sat, 7 Dec 1996 05:40:10 -0800 (PST) Mike Eisler wrote: >boris@ftp.com wrote: > >> --- On Mon, 2 Dec 1996 11:06:57 -0800 "Michael R. Eisler" >> wrote: >> >> > query for exported file systems >> > ------------------------------- >> > >> > It is proposed that the MOUNT protocol not be used for boot >> > strapping NFS Version 4 client/server sessions, and in its >> > place, a new procedure, SHAREINFO, be added. The SHAREINFO >> > procedure would return the list of exported file systems (by >> > path name). >> >> Why not just a READDIR? After all exports are just the directory files. >> As the starting point in this READDIR (instead of the Directory >> File Handle) we can use the mechanism proposed in the new LOOKUP. > >What file handle do you use with this READDIR? A special server's VIRTUAL file handle. > Consider the case of >an NFS server that exports dis-joint portions of its namespace: > > /export/home16 > > /pub > >If one just does a LOOKUP START_FROM_ROOT "/" from the client, my V4 server >is going to refuse the access, because / isn't exported. And even if it >did return a file handle, it won't permit a READDIR of "/" because "/" >is unexported. There might be a directory under "/" whose name I want >to keep confidential ... say "/the_boris_files" :-) "/" is totally UNIX-ish notation of the absolute root for a file system. Probably I have not completely understood you when I read about your 'virtual' root. Let me explain how I'd like to see it. Doing this I'll intentionally use VMS file notations that is as foreign for us (NT and W95 shops) as it is for you (UNIX people). Let's say VMS NFS server exported two directories: adsk:[dir1.dir2] bdsk:[foo.goo] I'd like to be able to issue a READDIR to the special server's VIRTUAL file handle representing a top level VIRTUAL directory on the server and get back the list of the exported files only 'adsk:[dir1.dir2]', 'bdsk:[foo.goo]' with their file handles and their attributes (for READDIRPLUS). The READDIRPLUS can additionally return some Extended Attributes (well defined in the protocol), describing special export-related properties. Clients should NOT make ANY assumptions about the semantics of the returned file names of these exports, but rather should treat them as single component names. An attempt to do READDIR for 'bdsk:[foo.goo]'\.. will NOT bring a client to 'bdsk:[foo]', but rather brings to the level of the VIRTUAL directory. SMB takes the idea that names of shares cannot be analyzed even further. It actually assigns a simple single-component names to shared directories. Thus it solves the security problem similar to one that you identified above: when we export a sub-tree "/Mike/the_boris_files" we may want to keep the real name of this sub-tree on a host computer confidential. The next release of our NFS server will give users an option to associate a simple name with an exported point. > >> >> > security flavor negotiation >> > --------------------------- >> It would be great to create a generic security model that is >> based on generic (non uid/gid) Identity, generic Object (server, >> file, etc.), and generic Rights. > >I'm open to suggestions. It would also be great to have a model that >doesn't introduce extra administration over and above the security >mechanism being used in the RPC header. Agree. But we should somehow break this knot when a file ownership Identity is described in UNIX terms of uid/gid because of RPC UNIX authentication and we use RPC UNIX authentication because it so conveniently matches the file ownership Identity model. > >> >Non-UNIX systems >> >================ >> > >> > [ Note this section has a PC-centric slant ] >> > >> > Export inheritance >> > ------------------ >> > The NFS protocol is specified to not let a NFS client cross >> > mount points. This is so the NFS client does not get confused >> > about the identity of files in the even two files on two >> > different server file systems share the same file id (inode #). >> > >> > This semantic is not desired by some clients, such as PC desk tops. >> > The proposal, as described previously, is to make >> > mount point crossing optional. >> >> The main advantage of NFS (compared to SMB) is its heterogeneous nature. >> Things like 'inode #' that can confuse clients and 'mount points' >> directly contradict this nature. > >A client that doesn't grok fileid doesn't have to use it right? I believe that file should be uniquely identifiable by one item only, the file handle. Redundancy is usually a source of a problem. Our server struggles to generate this field. At least let us put a 0 there, please. >> 7 Client Locks >> We need to add the ability for a client to inform a server >> that it is caching some ranges of files. This can be done >> using a mechanism similar to Blocked Locks. Clients >> should be able to issue special 'Client Locks'. >> The Client Lock means that the client is caching the file >> region specified in this lock. If no user locks are >> associated with the region, the requested Client Lock >> should be granted. Several different clients can issue >> Client Locks for overlapping file regions - these locks > ^^^^^^^^^^^^^^^^^^^^^^^^ >> should be granted since they do not conflict. If part of > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >This doesn't parse. Are these overlapping locks READ locks? Yes, here I was speaking only about the read cache support. > >> the region that was requested in the Client Lock request >> is already locked via another client's regular >> NLM Lock, the Client Lock should be denied. Any attempt >> to write into the regions protected by Client Locks, delete >> files, or even get a regular NLM lock for any part of the >> region should trigger a Client Lock Broken message from the >> server to the client. If the Client receives a Client Lock >> Broken message, the Client should discard the cache region >> specified in the message. > >Does the 2nd client that does the write have to block while the server >is delivering the Client Lock Broken message to 1st client? No, it does not. >How is this different from a full blown cache coherency (with all the >recovery problems)? This only supports the read cache. It covers about 70%-80% of what we want to cache. It does not have a problem that we see with the write cache when write cache buffers have to be flushed before completing the competing reads. In this simplified model we just have to inform clients that read cache buffers have to be discarded. Sorry, I fail to see how the recovery of such Client Locks is different from the recovery of the regular NLM locks. -----------------End of Original Message----------------- From nfs4-wg-request Sun Dec 8 09:36:25 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04773; Sun, 8 Dec 96 09:36:27 PST Return-Path: Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04769; Sun, 8 Dec 96 09:36:25 PST Received: from teal by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA10115; Sun, 8 Dec 1996 09:28:45 -0800 Date: Sun, 8 Dec 1996 09:28:16 -0800 (PST) From: Mike Eisler Reply-To: Mike Eisler Subject: RE: Kick-off discussion To: boris@ftp.com Cc: Mike Eisler , nfs4-wg@sunroof.eng.sun.com In-Reply-To: "Your message with ID" 961208043349.boris@ntbook> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO Content-Length: 9773 Lines: 222 boris@ftp.com writes: > --- On Sat, 7 Dec 1996 05:40:10 -0800 (PST) Mike Eisler > wrote: > > >boris@ftp.com wrote: > > > >> --- On Mon, 2 Dec 1996 11:06:57 -0800 "Michael R. Eisler" > >> wrote: > >> > >> > query for exported file systems > >> > ------------------------------- > >> > > >> > It is proposed that the MOUNT protocol not be used for boot > >> > strapping NFS Version 4 client/server sessions, and in its > >> > place, a new procedure, SHAREINFO, be added. The SHAREINFO > >> > procedure would return the list of exported file systems (by > >> > path name). > >> > >> Why not just a READDIR? After all exports are just the directory > files. >> As the starting point in this READDIR (instead of the > Directory >> File Handle) we can use the mechanism proposed in the > new LOOKUP. > > >What file handle do you use with this READDIR? > > A special server's VIRTUAL file handle. Sort of like the public file handle in WebNFS. > Probably I have not completely understood you when I read about your > 'virtual' root. Let me explain how I'd like to see it. Doing this I'll > intentionally use VMS file notations that is as foreign for us > (NT and W95 shops) as it is for you (UNIX people). In WebNFS, if one does: lookup fh=0x0 "export/home/mre" this is relative to a virtual root, much as ftp://server/pub/mre is relative to the home directory of the anonymous ftp user. Indeed this was one of the reasons why the virtual root concept was invented ... to make it easier for folks to transition off of anonymous ftp server to anonymous NFS servers. In WebNFS, one can override the virtual root with: lookup 0x0 "/export/home/mre" > Let's say VMS NFS server exported two directories: > adsk:[dir1.dir2] > bdsk:[foo.goo] > I'd like to be able to issue a READDIR to the special server's > VIRTUAL file handle representing a top level VIRTUAL directory > on the server and get back the list of the exported files only > 'adsk:[dir1.dir2]', 'bdsk:[foo.goo]' > with their file handles and their attributes (for READDIRPLUS). > The READDIRPLUS can additionally return some Extended Attributes > (well defined in the protocol), describing special export-related > properties. Clients should NOT make ANY assumptions about the > semantics of the returned file names of these exports, but rather > should treat them as single component names. It would be nice to consider getting away from native path name formats and go to canonical "/" separated forms. The rest of the Internet is moving in this direction. > An attempt to do READDIR for 'bdsk:[foo.goo]'\.. will NOT > bring a client to 'bdsk:[foo]', but rather brings to the level > of the VIRTUAL directory. > SMB takes the idea that names of shares cannot be analyzed > even further. It actually assigns a simple single-component names > to shared directories. Thus it solves the security problem > similar to one that you identified above: when we export a sub-tree > "/Mike/the_boris_files" we may want to keep the real > name of this sub-tree on a host computer confidential. Interesting. I wonder if treating file names of this special READDIR+ as single component names is going to cause problems for clients that are homogenous to the server. A UNIX server that exports "/export/foo" and then returns this as a single component in READDIR+ will break a UNIX client that tries to use the automounter to do: cd /net/server/export/foo Or if it doesn't break it, it makes it more complex to implement. One thing to keep in mind is thatwith SHAREINFO minimal information about the server is given out. With READDIR+ potentially lots of information is given out ... potentially without the appropritate security flavor/options. One could limit your special READDIR+ tojust the exported related properties. But then it starts to look semantically the same as SHAREINFO. It would interesting to get the perspective of automounter developers to see which kind of model would be easier to work with. SHAREINFO is essentially the same as functionallity offered in the MOUNT protocol. > >> > security flavor negotiation > >> > --------------------------- > >> It would be great to create a generic security model that is > >> based on generic (non uid/gid) Identity, generic Object (server, > >> file, etc.), and generic Rights. > > > >I'm open to suggestions. It would also be great to have a model that > >doesn't introduce extra administration over and above the security > >mechanism being used in the RPC header. > > Agree. > But we should somehow break this knot when a file ownership > Identity is described in UNIX terms of uid/gid because of RPC UNIX Note that is is highly unlikey IESG will elevate any output of this working group to proposed standard if the best we can do for NFS V4 is AUTH_SYS. > authentication and we use RPC UNIX authentication because it so > conveniently matches the file ownership Identity model. I agree. My hope is that if say a client/server uses Kerberos, that GETATTR could return ownership in terms of Kerberos principals. Whether the file is stored with Kerberos principal names or not on the server is immaterial. If the server is using say UNIX uids, it has to be able to map Kerberos principal names to uids anyway. The problem with coming with a canonical universal Identity for users is that this would add a layer of administration to map: universal Identifty <--> local Indentity The administrator already has to deal with local Identity <--> security mechanism identity such as with AUTH_DES, AUTH_KERB, and hopefully soon RPCSEC_GSS. > >> The main advantage of NFS (compared to SMB) is its heterogeneous > nature. >> Things like 'inode #' that can confuse clients and 'mount > points' >> directly contradict this nature. > > > >A client that doesn't grok fileid doesn't have to use it right? > > I believe that file should be uniquely identifiable by one item > only, the file handle. Redundancy is usually a source of a problem. > Our server struggles to generate this field. At least let us put > a 0 there, please. Initially, going in to this, I thought that attributes like file ids ought to be mandatory, but you aren't the only one who has said that this is hard to to do on non-UNIX platforms. It's something we have to consider. BTW, rather than letting you put in 0, if we were to make fileid's optional, I'd prefer a scheme that just flags the attribute as unsupported. Perhaps there would be a bit vector of the basic attributes (borrowing an idea from Brent C.), and if the bit is off, the client wouldn't interpret or receive that attribute. Recall the problems with NFS V2 by letting people stick -1 in attributes that weren't supported. > >> 7 Client Locks > >> We need to add the ability for a client to inform a server > >> that it is caching some ranges of files. This can be done > >> using a mechanism similar to Blocked Locks. Clients > >> should be able to issue special 'Client Locks'. > >> The Client Lock means that the client is caching the file > >> region specified in this lock. If no user locks are > >> associated with the region, the requested Client Lock > >> should be granted. Several different clients can issue > >> Client Locks for overlapping file regions - these locks > > ^^^^^^^^^^^^^^^^^^^^^^^^ > >> should be granted since they do not conflict. If part of > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > >This doesn't parse. Are these overlapping locks READ locks? > > Yes, here I was speaking only about the read cache support. > > > > >> the region that was requested in the Client Lock request > >> is already locked via another client's regular > >> NLM Lock, the Client Lock should be denied. Any attempt > >> to write into the regions protected by Client Locks, delete > >> files, or even get a regular NLM lock for any part of the > >> region should trigger a Client Lock Broken message from the > >> server to the client. If the Client receives a Client Lock > >> Broken message, the Client should discard the cache region > >> specified in the message. > > > >Does the 2nd client that does the write have to block while the server > >is delivering the Client Lock Broken message to 1st client? > > No, it does not. Ok, this starting to sound good. So in other words, if the first client is partitioned or has crashed when the write from the 2nd client arrives, the 2nd client is unaffected. > >How is this different from a full blown cache coherency (with all the > >recovery problems)? > > This only supports the read cache. It covers about 70%-80% > of what we want to cache. It does not have a problem that we see > with the write cache when write cache buffers have to be flushed before > completing the competing reads. In this simplified model we just > have to inform clients that read cache buffers have to be discarded. > Sorry, I fail to see how the recovery of such Client Locks is > different from the recovery of the regular NLM locks. I just wanted to make sure that the 2nd client wouldn't block waiting for the 1st client callback to complete. If that weren't true it would be indistinguishable from full cache consistency. I agree that recovery of the Client locks that doesn't affect clients that aren't locking the file is no different than regular NLM locks. I would like to see a better recovery algorithm for locks ... I find the elegance of Spritely-NFS token recovery quite attractive. -mre From nfs4-wg-request Mon Dec 9 13:37:54 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06188; Mon, 9 Dec 96 13:37:55 PST Return-Path: Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06184; Mon, 9 Dec 96 13:37:54 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA07750; Mon, 9 Dec 1996 13:30:13 -0800 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA13385; Mon, 9 Dec 1996 13:29:48 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA04458; Mon, 9 Dec 1996 13:29:36 -0800 Received: from bigfun.engr.sgi.com (fddi-bigfun.engr.sgi.com [192.26.75.20]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA21196; Mon, 9 Dec 1996 12:54:48 -0800 Received: by bigfun.engr.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id MAA14520; Mon, 9 Dec 1996 12:53:37 -0800 Date: Mon, 9 Dec 1996 12:53:37 -0800 From: kessler@bigfun.engr.sgi.com (Tom Kessler) Message-Id: <199612092053.MAA14520@bigfun.engr.sgi.com> To: brent.callaghan@Eng (Brent Callaghan) Subject: Re: Minor versioning In-Reply-To: <199612070405.UAA10870@terra.eng.sun.com> References: <199612070405.UAA10870@terra.eng.sun.com> Cc: nfs4-wg@sunroof.eng.sun.com Status: RO Content-Length: 1061 Lines: 30 Brent Callaghan writes: > > Minor versioning also has a good marketing rationale. And bad product rationale :-( > > Motivation for vendors to keep their implementation up-to-date. There are plusses and minuses to this. It means protocol updates become more of an ongoing continuous sort of activity as opposed to a major project every say 2-3 years. I don't know about the current politics in your neck of the woods but I find it easier to fund a larger project that has a pile 'o features people really want. > > If company X advertises NFS V4.2 and company Y is only at V4.1 > then company Y is motivated to support V4.2. And it adds another level of complexity to interoperability testing. Now I need to test my version 4.4 against your versions 4.0, 4.1, 4.2, etc. > > Of course, Joe customer doesn't care what's *in* version V4.2, > but the bigger number means "better" right ? :-) Oh spare me, I've got enough work to do without playing rev wars. I really do prefer the larger chunks with tangible user benefits from the changes. From nfs4-wg-request Mon Dec 9 21:34:54 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06700; Mon, 9 Dec 96 21:34:55 PST Return-Path: Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06696; Mon, 9 Dec 96 21:34:54 PST Received: from shasta1.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA15918; Mon, 9 Dec 1996 21:27:15 -0800 Received: by shasta1.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA01549; Mon, 9 Dec 1996 21:25:28 -0800 Date: Mon, 9 Dec 1996 21:25:28 -0800 From: mre@pacific-86 (Michael R. Eisler) Message-Id: <199612100525.VAA01549@shasta1.eng.sun.com> To: bkessler@bigfun.engr.sgi.com Subject: Re: Minor versioning Cc: nfs4-wg@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 1835 Lines: 42 > From kessler@bigfun.engr.sgi.com Mon Dec 9 13:30:42 1996 > Brent Callaghan writes: > There are plusses and minuses to this. It means protocol updates > become more of an ongoing continuous sort of activity as opposed to > a major project every say 2-3 years. I don't know about the current > politics in your neck of the woods but I find it easier to fund a > larger project that has a pile 'o features people really want. NFS industry history with respect to NFS V3, NFS ACL protocols (at least three that I know off), suggests that your situation is not the industry norm. > > If company X advertises NFS V4.2 and company Y is only at V4.1 > > then company Y is motivated to support V4.2. > > And it adds another level of complexity to interoperability testing. > Now I need to test my version 4.4 against your versions 4.0, 4.1, 4.2, etc. Being forced to test your versions 8,7,6,5,4 against Brent's 8,7,6,5,4 is going to be easier? With a major version update, all kinds of protocol characteristics can change. Between 4.0 and 4.1 I would not expect the maximum file size to go from 2^64 to 2^128, but between 2 and 3 we saw it go from 2^32 to 2^64. > > Of course, Joe customer doesn't care what's *in* version V4.2, > > but the bigger number means "better" right ? :-) > I really do prefer the larger chunks with tangible user benefits from > the changes. While large feature chunks often amount to lots of tangible benefits to users, the corrollary that incremental features omount to few tangible benefits. User's would have benefited big time if safe async writes could have been added to NFS V2. This would have been a very small chunk with very large tangible benefits. Ditto an ACCESS procedure. Many if not most customers would not need to migrate to V3 if V2 had three simple procedures added. -mre From nfs4-wg-request Tue Dec 10 14:25:29 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07488; Tue, 10 Dec 96 14:25:31 PST Return-Path: Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07484; Tue, 10 Dec 96 14:25:29 PST Received: from shasta1.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA15403; Tue, 10 Dec 1996 14:17:48 -0800 Received: by shasta1.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA00930; Tue, 10 Dec 1996 14:16:01 -0800 Date: Tue, 10 Dec 1996 14:16:01 -0800 From: mre@pacific-86 (Michael R. Eisler) Message-Id: <199612102216.OAA00930@shasta1.eng.sun.com> To: kessler@bigfun.engr.sgi.com, mre@pacific-86 Subject: Re: Minor versioning Cc: nfs4-wg@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 500 Lines: 13 > From mre@pacific-86 Mon Dec 9 21:27:43 1996 > > I really do prefer the larger chunks with tangible user benefits from > > the changes. > > While large feature chunks often amount to lots of tangible benefits to > users, the corrollary that incremental features omount to few tangible > benefits. let's try this part again: While large feature chunks often amount to lots of tangible benefits to users, the corollary that incremental features amount to few tangible benefits is not always true. From nfs4-wg-request Wed Dec 18 18:00:48 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21292; Wed, 18 Dec 96 18:00:50 PST Return-Path: Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21288; Wed, 18 Dec 96 18:00:48 PST Received: from terra.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA20030; Wed, 18 Dec 1996 17:52:58 -0800 Received: by terra.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA21347; Wed, 18 Dec 1996 17:48:34 -0800 Date: Wed, 18 Dec 1996 17:48:34 -0800 From: brent@jurassic (Brent Callaghan) Message-Id: <199612190148.RAA21347@terra.eng.sun.com> To: nfs4-wg@sunroof.eng.sun.com Subject: Draft of NFS V4 BOF minutes X-Sun-Charset: US-ASCII Status: RO Content-Length: 6368 Lines: 169 Here's a draft of the BOF minutes. If you were there and you see anything that is incorrect or missing, please let me know by Friday and I'll make corrections before forwarding to the minutes alias. Thanks Brent ______________________________________________ NFS V4 BOF Minutes San Jose IETF, December 1996, As reported by Brent Callaghan (Sun) with assistance from Jon Dreyer (Sun). Brent Callaghan welcomed the participants by describing the motivation for doing an NFS protocol revision within the context of IETF and followed with an introduction to NFS: its design principles, its history, the design motivations and process for version 3, and presented WebNFS as a motivation for further work on the NFS protocol in version 4. He then introduced Mike Eisler (Sun) who covered the wish-list items for version 4 and solicited feedback from the BOF participants. In summary, the wish-list items are: - Internationalisation - Facilitate operation on the Internet - Improved security semantics - Integrated Locking - Embrace non-Unix systems - Better support for caching - Protocol extensibility Some of these items had been discussed previously on the nfs4-wg@sunroof.eng.sun.com mailing list. Mike summarized these discussions in his presentation. The following notes summarise BOF discussion on some of these items: On Internationalisation: Case mapping is language-dependent, but unicode specifies pretty good language-independent case mapping. Perhaps server can translate OTW character set to local character set before doing case mapping, but need to deal with possibility that some OTW chars may not translate to local character set. On facilitating operation on the Internet: Brian Pawlowski of Network Appliance mentioned that the bundling of locking with the NFS protocol will not in itself "fix" locking. He was concerned that a running the protocol over TCP is not necessarily a good move since UDP still currently outperforms TCP on LANs and TCP introduces scalability problems with connection state on the server. Brent mentioned that web servers already cope with very heavy connection loads and that there are techniques available for servers to manage connection overhead. On embrace of non-Unix systems: Brian is concerned that if we add stuff like a "hidden" bit for better PC semantics and few servers supported it we may be worse off. Boris Zuckerman from FTP argued that the protocol should support wildcard semantics. "Just because it's difficult doesn't mean we shouldn't do it." Jon Dreyer is concerned that it's not really possible without also adding protocol support for 8.3 names, since filenames with wildcards may contain 8.3 components. He views protocol support for 8.3 names as an anachronistic nightmare. On protocol extensibility: Adding extensions means there's more than one protocol. Some concern was expressed that this might facilitate creeping featurism and make testing of multiple minor-versions more difficult. Providing support for arbitrary named attributes might cause problems with name space clashes, e.g. two clients might assign different semantics to attribute "frobnitz." Someone proposed using something like an OID to identify attributes rather than names. But this handles only protocol-defined attributes rather than arbitrary name-value attributes. There was some discussion as to how named attributes might be stored in filesystems that do not support them. Mike Eisler mentioned that a directory can be thought of as containing named attributes each with arbitrary data. There was some concern as to how the protocol would cater to clients and servers that mutually identify with a particular set of filesystem semantics and wish to use them, e.g. where a Windows NT client identifies the server as a Windows NT server and needs full NTFS semantics. Several people expressed the opinion that the protocol should not stray into this dangerous ground. On security mechanisms: Jon Dreyer was surprised about the requirement that to be a conformant implementation must implement all security mechanism in the identified gss-api mechanisms, especially with lightweight clients like the toaster. Mike Eisler reaffirmed this requirement. On additional items: Tom Kessler asked if the protocol should support the use of proxy servers. Brent Callaghan replied that proxying was not possible with the current protocol versions and that it would be useful for V4 to support proxying. Mike Eisler mentioned that the current model of persisent filehandles is limiting and that a dynamic filehandles backed by pathnames that permit recovery of filehandle data would be more useful. Version 4 could tag filehandles with a hint as to its volatility. The client could use this information to decide whether to cache the pathname corresponding to the filehandle. How about adding a copy procedure to the protocol so if OSs support it later we can support it? Many felt that second-guessing the future tends to add useless baggage because we second-guess wrong. Brian Pawlowski asked a rhetorical question: "Why don't we just adopt DFS?" Mike Eisler replied that OSF/Open Group isn't bringing it to the table. Brent concluded the BOF with a summary of actions required for working group formation. Working group chair(s) would need to be approved by the ADs. Current candidates for co-chairs are Brent Callaghan (Sun) and Spencer Shepler (IBM). The current WG mailing list addresses are: nfs4-wg@sunroof.eng.sun.com nfs4-wg-request@sunroof.eng.sun.com He reminded the attendees that the draft WG charter would need to be approved by those on the mailing list along with a list of milestones. He suggested that a working draft of the protocol should be ready a month ahead of the next IETF meeting (April) and that the upcoming Connectathon event late February in South San Francisco would be a good venue for an initial review and feedback. Keith Moore polled the attendees (~60) for their interest in participating in an NFS V4 Working Group and received an apparently unanimous show of hands. ______________________________________________ From nfs4-wg-request Mon Dec 23 18:46:55 1996 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28061; Mon, 23 Dec 96 18:46:56 PST Return-Path: Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28057; Mon, 23 Dec 96 18:46:55 PST Received: from terra.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA07941; Mon, 23 Dec 1996 18:38:54 -0800 Received: by terra.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA04182; Mon, 23 Dec 1996 18:38:39 -0800 Date: Mon, 23 Dec 1996 18:38:39 -0800 From: brent@caribe-86 (Brent Callaghan) Message-Id: <199612240238.SAA04182@terra.eng.sun.com> To: nfs4-wg@sunroof Subject: Draft NFS V4 WG Charter & Milestones X-Sun-Charset: US-ASCII Status: RO Content-Length: 3104 Lines: 108 Hi, I'm laying some groundwork in preparation for formation of the NFS V4 WG at IETF. I don't expect a final decision on this until the IESG sees a signed document giving protocol change control to ISOC. Currently this document is being reviewed by both Sun and ISOC. Meanwhile, I'd like to get some agreement on a draft Working Group Charter and Milestones. These are important - they're a tool used by the WG chairs to keep the WG focused on the job at hand and on track with it's deliverables. I've taken the draft charter that appeared in the BOF announcement (rather brief) and added some text to disambiguate. I'd appreciate comments: - Is there anything that should be added/removed/changed ? - Is it unambiguous ? - Is it what we want to do ? If you would like to compare with other WG charters and milestones, take a look at http://www.ietf.org/html.charters/wg-dir.html Happy holidays! Brent _______________________________________ Description of Working Group ---------------------------- The objective of this working group is to advance the state of NFS technology by producing a specification for NFS version 4 which will also be submitted as an Internet standard. NFS version 4 will emphasize the following core features: o Improved access and good performance on the Internet. The protocol will be designed to transit firewalls easily, perform well where latency is high and bandwidth is low, and scale to very large numbers of clients per server. o Strong security with negotiation built into the protocol. The protocol will build on the work of the ONCRPC working group in supporting the RPCSEC_GSS protocol. Additionally NFS version 4 will provide a mechanism to allow clients and servers to negotiate security and require clients and servers to support a minimal set of security schemes. o Better cross-platform interoperability. The protocol will feature a filesystem model that provides a useful, common set of features that does not unduly favor one filesystem or operating system over another. o Designed for protocol extensions. The protocol will be designed to accept standard extensions that do not compromise backward compatibility. The NFS version 4 protocol will emphasize, but not be limited to these core features. Additional improvements will be considered if they are considered reasonable, useful, and do not conflict with the core features. Goals and Milestones -------------------- Feb 97 Meet to discuss strawman proposal at Connectathon. Mar 97 Submit an strawman Internet Draft of the protocol. Apr 97 First meeting of WG at Memphis IETF. Aug 97 Second meeting of WG at Munich IETF Dec 97 Submit NFS version 4 to IESG for consideration as Proposed Draft. Jun 98 Submit NFS version 4 to IESG for consideration as Draft Standard. _______________________________________ From nfs4-wg-request Fri Feb 7 16:02:05 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA04686; Fri, 7 Feb 1997 16:02:05 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA04683; Fri, 7 Feb 1997 16:02:04 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA29701; Fri, 7 Feb 1997 16:02:24 -0800 Received: from distinct.com (distinct.com [198.211.122.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA13583 for ; Fri, 7 Feb 1997 16:02:27 -0800 Received: from calculus.distinct.com (calculus1) by distinct.com (5.x/SMI-SVR4) id AA03188; Fri, 7 Feb 1997 15:47:42 -0800 Received: (rajen@localhost) by calculus.distinct.com (8.6.8.1/SCA-6.6) id XAA10579 for nfs4-wg@sunroof.eng.sun.com; Fri, 7 Feb 1997 23:48:39 GMT From: "V.Rajendran" Message-Id: <199702072348.XAA10579@calculus.distinct.com> Subject: Is something happening or it is me who is missing something / To: nfs4-wg@sunroof.eng.sun.com Date: Fri, 7 Feb 1997 15:48:39 -0800 (PST) Sender: V.Rajendran@calculus.distinct.com Status: RO Content-Length: 463 Lines: 19 Telephone (work) : +1-408-366-8933 FAX (work): +1-408-366-0153 Reply-To : rajen@distinct.com Return-Receipt-To : rajen@distinct.com Address : --------------------------------------------------------------- Office : Distinct Corporation 12900 Saratoga Ave. , Saratoga , CA95970. USA. --------------------------------------------------------------- X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 27 Subject says it all. Raj. From nfs4-wg-request Fri Feb 7 17:32:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA04980; Fri, 7 Feb 1997 17:32:57 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA04977; Fri, 7 Feb 1997 17:32:56 -0800 Received: from terra.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA08548; Fri, 7 Feb 1997 17:33:19 -0800 Received: by terra.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA01155; Fri, 7 Feb 1997 17:33:18 -0800 Date: Fri, 7 Feb 1997 17:33:18 -0800 From: brent@caribe-86 (Brent Callaghan) Message-Id: <199702080133.RAA01155@terra.eng.sun.com> To: rajen@calculus.distinct.com Subject: Re: Is something happening or it is me who is missing something ? Cc: nfs4-wg@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 615 Lines: 17 > Is something happening or it is me who is missing something ? No, I don't think you've missed anything. In the previous round of Emails a few weeks ago we were discussing some of the wish-list items that Mike Eisler posted earlier though it's hard to get to grips with a wish-list. I'm sure the Email will fly when we make the first strawman Internet-Draft available for all to throw rocks at, hopefully in a few weeks. At Connectathon in South San Francisco (starts Feb 26th - see http://www.sun.com/sunsoft/connectathon ) we'll be able to present some of the candidate features for the strawman. Brent From nfs4-wg-request Thu Feb 13 16:20:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA13091; Thu, 13 Feb 1997 16:20:31 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA13088; Thu, 13 Feb 1997 16:20:26 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA06333; Thu, 13 Feb 1997 16:20:50 -0800 Received: from darius.concentric.net (darius.concentric.net [207.155.184.79]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA04230 for ; Thu, 13 Feb 1997 16:20:38 -0800 Received: from newman.concentric.net (newman.concentric.net [207.155.184.71]) by darius.concentric.net (8.8.5/(97/02/12 3.22)) id TAA04675; Thu, 13 Feb 1997 19:17:58 -0500 (EST) [1-800-745-2747 The Concentric Network] Errors-To: Received: from srinivas.concentric.net ([207.155.161.17]) by newman.concentric.net (8.8.5) id TAA27216; Thu, 13 Feb 1997 19:17:52 -0500 (EST) Message-Id: <3.0.32.19970213161839.00692ddc@smtp.concentric.net> X-Sender: sbharadw@smtp.concentric.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 13 Feb 1997 16:18:45 -0800 To: nfs4-wg@sunroof.eng.sun.com From: Srinivas Bharadwaj Subject: Please add to interest list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Status: RO Content-Length: 58 Lines: 3 Hi! Please add me to the interest list for NFS V4. srini From nfs4-wg-request Tue Mar 4 23:48:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA13611; Tue, 4 Mar 1997 23:48:25 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA13608; Tue, 4 Mar 1997 23:48:24 -0800 Received: from notnerb by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA09929; Tue, 4 Mar 1997 23:48:57 -0800 Date: Tue, 4 Mar 1997 23:46:07 -0800 (PST) From: Brent Callaghan Reply-To: Brent Callaghan Subject: Heads Up: Security Requirements for Working Groups (Fwd) To: nfs4-wg@sunroof.eng.sun.com Message-ID: Content-Type: text X-Sun-Text-Type: ascii Status: RO Content-Length: 6344 Lines: 127 FYI: these are suggested security guidelines for working groups to consider in writing new RFCs. At the BOF last December in San Jose we mentioned the need for NFS v4 to make use of strong security through the ONCRPC RPCSEC_GSS mechanism (Internet-Draft draft-ietf-oncrpc-rpcsec_gss-02.txt ) and having security negotiated within the NFS protocol. While the secure authentication, message integrity, and privacy available through RPCSEC_GSS will go a long way to securing the protocol from threats, the IETF expect more rigorous analysis of the susceptibilities of a protocol than in the past, e.g. an authenticated client could re-export NFS filesystems to unauthenticated clients. Any comments on the proposed security requirements (below) ? Brent >----------------Begin Forwarded Message----------------< Date: Tue, 4 Mar 1997 17:31:20 -0500 From: "Fred Baker" Subject: Heads Up: Security Requirements for Working Groups To: bofchairs@ietf.org, wgchairs@ietf.org Cc: jte@cert.org For your comment... Some IAB, IESG, and Security folks have been meeting this week to discuss the improvement of security analysis in Internet protocols. Over the past few years, CERT Advisories and the media have made it brutally clear that many protocols and many implementations are subject to various threats, and writing a protocol or implementing a procedure that is naive in this regard is at best silly and at worst a culpable disservice. Section 2.2 of RFC 1603, which indicates that the charter of a working group, and therefore its documents, should address security among other things. We feel that part of this is requirements of working groups in their charter and in their resulting documents. I'd like to run some of the preliminary recommendations by you for your comment. Guidelines on writing Security Considerations in an RFC A "threat" is, by definition, a vulnerability available to a motivated and capable adversary. CERT advisories are quite predictable given a knowledge of the target of the threat; they therefore represent an existence proof, not a threat analysis. The point is to determine what attacks are possible ("capabilities" of a potential attacker) and formulate a defense against the attacks, or convincingly argue that the attack is not realistic in some environment and restrict use of the protocol to that environment. Recommended guidelines: - All RFCs must meaningfully address security in the protocol or procedure it specifies. It must consider that it is giving its data to "the enemy" and asking it to be delivered to its friends and used in the manner it intended. Consideration must be given to the ramifications of the inherent danger of the situation. - Must do "due diligence" to list the threats to which the protocol is vulnerable. Use of legal term does not imply legal liability, but level of responsibility expected to be applied to the analysis. This discussion might occur throughout the document or in the Security Considerations section; if it occurs throughout, it should be summarized and referenced in the Security Considerations section. - Must discuss which of those threats are * Ameliorated by protocol mechanisms (example: SYN attack is ameliorated by clever code that drops sessions randomly when under SYN attack) * Ameliorated by reliance on external mechanisms (example: TCP data confidentiality provided by IPSEC ESP) * Irrelevant ("In most cases, MIBs are not themselves security risks; If SNMP Security is operating as intended, the use of a MIB to change the configuration of a system is a tool, not a threat. For a threat analysis of SNMP Security, see RFC ZZZZ.") * Not addressed by the protocol; results in applicability statement. ("This protocol should not be used in an environment subject to this attack") - Principle: new protocols and practices ought not worsen overall security of the Internet. - Principle: reuse an existing protocol or mechanism if possible... - When cryptographic algorithms are used, enable the substitution of other algorithms in the future - Should discuss implementation hints or guidelines * handle race conditions * handle buffer overflows/off-by-one issues * source code integrity * principle of least privilege * deal with untrustworthy data * deal with untrustworthy peer systems Description of minimal Internet threat environment Implied by the above is that the security folks need to provide an Informational RFC that gives RFC authors a hand in doing the analysis. The idea is not to impose a requirement - the requirement already exists, and is handled today by back pressure during document last call and IESG review - but to provide a tool that will help working groups and independent submitters produce documents that do not result in that particular back pressure. It lists classes of attacks and modes of analysis that the security folks find useful. An initial goal is to post an internet draft in April and deliver an initial RFC by August. - Classes of attacks in current CERT advisories are within the minimal threat environment - Other known classes of attacks may be as well - Should include a taxonomy/glossary of classes of attacks and terminology, with examples. - Republish periodically as IAB/IESG deem appropriate Adding Security Requirements to WG Charters - Each WG is responsible for addressing security in its context - Each WG charter (including old ones, updated during 2Q97) contains at minimum the words "This working group acknowledges the importance of security in the overall internet architecture. Therefore, the protocols developed by this working group will be analyzed relative to RFCs XXXX and YYYY, to identify relevant security characteristics, dependencies on other security technology, and any residual vulnerabilities. This analysis will form the core of the Security Considerations section of the resulting RFC." - Each WG needs to work with "security volunteers" as it progresses its work. - No "Security will be added later" >----------------End Forwarded Message----------------< From nfs4-wg-request Wed Mar 5 01:27:26 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA13635; Wed, 5 Mar 1997 01:27:26 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA13632; Wed, 5 Mar 1997 01:27:25 -0800 Received: from peyto.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA13605; Wed, 5 Mar 1997 01:28:04 -0800 Received: by peyto.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA16193; Wed, 5 Mar 1997 01:26:45 -0800 Date: Wed, 5 Mar 1997 01:26:45 -0800 From: mre@jurassic (Michael R. Eisler) Message-Id: <199703050926.BAA16193@peyto.eng.sun.com> To: nfs4-wg@sunroof.eng.sun.com, brent@jurassic Subject: Re: Heads Up: Security Requirements for Working Groups (Fwd) X-Sun-Charset: US-ASCII Status: RO Content-Length: 700 Lines: 18 > From brent@jurassic Tue Mar 4 23:49:39 1997 [...] > threats, the IETF expect more rigorous anal