http://blog.gmane.org/gmane.ietf.nfsv4 hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.nfsv4/13035 <pre> RFC 5661 has the following text: Note that operations zero and one are not defined for the COMPOUND procedure. Operation 2 is not defined and is reserved for future definition and use with minor versioning. If the server receives an operation array that contains operation 2 and the minorversion field has a value of zero, an error of NFS4ERR_OP_ILLEGAL, as described in the next paragraph, is returned to the client. If an operation array contains an operation 2 and the minorversion field is non-zero and the server does not support the minor version, the server returns an error of NFS4ERR_MINOR_VERS_MISMATCH. Therefore, the NFS4ERR_MINOR_VERS_MISMATCH error takes precedence over all other errors. But RFC 5661 doesn't define an operation 2. Is operation 2 intended to be a sort of "minor version ping"? If so, I would assume it has no parameters. Thanks Frank_______________________________________________ nfsv4 mailing list nfsv4&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/nfsv4 </pre> Frank S Filz 2013-05-23T21:05:29 http://comments.gmane.org/gmane.ietf.nfsv4/13033 <pre> The following section: 9.4. Blocking Locks Some clients require the support of blocking locks. The NFS version 4 protocol must not rely on a callback mechanism and therefore is unable to notify a client when a previously denied lock has been granted. Clients have no choice but to continually poll for the lock. This presents a fairness problem. Two new lock types are added, READW and WRITEW, and are used to indicate to the server that the client is requesting a blocking lock. The server should maintain an ordered list of pending blocking locks. When the conflicting lock is released, the server may wait the lease period for the first waiting client to re-request the lock. After the lease period expires the next waiting client request is allowed the lock. Clients are required to poll at an interval sufficiently small that it is likely to acquire the lock in a timely manner. The server is not required to maintain a list of pending blocked locks as it is used to increase fairness and not correct operation. Bec</pre> Frank S Filz 2013-05-21T18:45:55 http://comments.gmane.org/gmane.ietf.nfsv4/13011 <pre>The objective of this feature is to improve NFS client caching for NFS4.3 I would like to find out from the group if one, others see this as a useful addition to NFS, and two, if extending the delegations feature is the right approach. The requirements as I see them is to make NFS client caching possible while maintaining its coherency without changing the NFS client applications. Have better synchronization of data among applications on different NFS clients while caching data. The options that we have today for more synchronization of data among NFS clients is direct IO which means no data caching. With delegations we can have caching on multiple NFS client readers or a single NFS client writer. It would be nice to make better use of delegations and more specifically the combination of read write delegation. In general the just read delegations are useful but the combination with write delegation are less useful for most cases. Selecting delegation as the synchronization method and </pre> Marc Eshel 2013-05-20T17:33:07 http://comments.gmane.org/gmane.ietf.nfsv4/13004 <pre>Hi Spencer So, I have had zero comments on this draft. AFAICS this means: a) The subject is of no interest b) The subject is of interest but the draft is horrible c) The subject is of mild interest and eveyone is busy d) The subject is of interest and the draft is perfect I'd like it to be "d" but I don't believe it :) Anyway, I'm not putting any more time into multi-domain work until this draft is either put to rest or commented on. --&gt;Andy _______________________________________________ nfsv4 mailing list nfsv4&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/nfsv4 </pre> Andy Adamson 2013-05-17T20:32:32 http://comments.gmane.org/gmane.ietf.nfsv4/13003 <pre>Hi Tom- FATTR4_CHNAGE_SEC_LABEL = 81; </pre> Chuck Lever 2013-05-17T20:16:09 http://comments.gmane.org/gmane.ietf.nfsv4/12999 <pre> RFC 3530 bis contains the following statement: Some clients require the support of blocking locks. The NFS version 4 protocol must not rely on a callback mechanism and therefore is unable to notify a client when a previously denied lock has been granted. Clients have no choice but to continually poll for the lock. This presents a fairness problem. Two new lock types are added, READW and WRITEW, and are used to indicate to the server that the client is requesting a blocking lock. The server should maintain an ordered list of pending blocking locks. When the conflicting lock is released, the server may wait the lease period for the first waiting client to re-request the lock. After the lease period expires the next waiting client request is allowed the lock. Clients are required to poll at an interval sufficiently small that it is likely to acquire the lock in a timely manner. The server is not required to maintain a list of pending blocked locks as it is used to increase fairness and not correct operation.</pre> Frank S Filz 2013-05-16T21:17:18 http://comments.gmane.org/gmane.ietf.nfsv4/12967 <pre> Hello, The following bis document expired 8 months ago and is part of the working group's charter. http://tools.ietf.org/id/draft-ietf-nfsv4-rfc5664bis-01.txt Please provide a timeline for updates or an opinion that the work should be removed from the charter and the WG's milestones. Thanks, Spencer _______________________________________________ nfsv4 mailing list nfsv4&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/nfsv4 </pre> Spencer Shepler 2013-05-15T05:45:57 http://comments.gmane.org/gmane.ietf.nfsv4/12966 <pre> My copy-paste from another email thread is mildly inappropriate but I thought it best to continue this discussion under a separate topic to ensure that everyone has had a chance to comment (see thread content in question below). The topic is completing the NFSv4.2 work and by association the RPCSEC_GSSv3 I-D. As my original email noted, the NFSv4.2 I-D has a normative reference on the RPCSEC_GSSv3 I-D. At this point, we have no editor for the RPCSEC I-D. So the first order of business is that I am soliciting an editor for http://tools.ietf.org/id/draft-williams-rpcsecgssv3-02.txt You will note the I-D expired 18 months ago. Second order of business is to decide whether to keep the dependency and if not, what can or should be done about it. Bruce suggested three choices (enumerated below). I am soliciting discussion on those choices (and if there are more). Opinions? Spencer On Fri, May 10, 2013 at 08:37:28PM -0400, David Quigley wrote: I can't volunteer for the </pre> Spencer Shepler 2013-05-15T05:37:07 http://comments.gmane.org/gmane.ietf.nfsv4/12959 <pre> In preparation in meeting the deadline for meeting requests as posted here (http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF87), Please send me your ideas and commitments to the agenda. Given that June 3rd is a Monday, please attempt to submit your agenda items by May 31st to allow for roll-up, etc. Spencer _______________________________________________ nfsv4 mailing list nfsv4&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/nfsv4 </pre> Spencer Shepler 2013-05-14T18:54:02 http://comments.gmane.org/gmane.ietf.nfsv4/12882 <pre>As to agenda items I might present/lead: * I'd like to give a talk about our versioning model and our options for changing it (in a positive way I hope). This will touch on the issues that have previously been discussed under the 'microversioning' rubric, but the focus will be different. Instead of only focusing on better ways to patch our mistakes , I'd like us to look at options to specify experimental versions to enable us to have working code earlier in the process, so finding problems earlier and avoiding work specifying features that never get significant implementation experience. If there is someone of the microversioning persuasion that wants to participate, perhaps we can collaborate on a joint presentation. * I'm willing to talk about the migration stuff but I think the priority of that for meeting time is low. I can spend a few minutes exhorting people to carefully read the document draft, but I think we need people doing implementations, to really find and document problem</pre> Noveck, David 2013-05-07T19:52:38 http://comments.gmane.org/gmane.ietf.nfsv4/12881 <pre> RFC 3530 only indicates that grace period SHOULD NOT be less than lease period. Is there any guidance? Do clients renew more frequently (say 1/2 lease period) such that grace period being the same as lease period should generally be sufficient? Thanks Frank_______________________________________________ nfsv4 mailing list nfsv4&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/nfsv4 </pre> Frank S Filz 2013-05-07T17:57:31 http://comments.gmane.org/gmane.ietf.nfsv4/12867 <pre>It seems to me that we should be discussing what we want to talk about at IETF87. I know that it is strange to be working on this so far in advance, but it appears to me that if we don't have that discussion pretty soon, there will be no nfsv4 meeting at IETF87. My feeling is that most of the members of the working group would not find that a very good outcome but I'm prepared for people to tell me that they are happy/OK with this result. Later I'll get back to some of the lead-time issues that lead me to my conclusion above. There may be some confusion about how and when we will decide on this. In fact I know that there is some confusion about this, since I know I'm confused about it. Maybe others are as well. If I recall correctly, some of this confusion arose when Spencer announced (on behalf of him and Beepy) that the working group co-chairs would monitor the working group list and then on the basis of list activity decided, on a basis never made clear , whether we would meet in Berlin. I then r</pre> Noveck, David 2013-05-05T14:39:08 http://comments.gmane.org/gmane.ietf.nfsv4/12855 <pre>Hello all, RFC 5661 quotes the below regarding the non-usefulness of Release_LockOwner for NFSv4.1 o RELEASE_LOCKOWNER because lock-owners with no associated locks do not have any sequence-related state and so can be deleted by the server at will. A few questions based on the above: a) Does it mean that the server can delete the state object and the lock owner as soon as it gets a LOCKU that releases the last lock under that particular owner? Or Is it better to wait for some time and see a freestateid on the last state before going ahead and deleting the state and hence the owner? b) What happens if the server is aggressive and deletes the owner immediately after the  LOCKU on the last lock and the client uses the aforementioned deleted state for a further LOCK request? would BAD_STATE_ID be the right error to return in this case and is it fair to assume  that the clients would recover again  by establishing state? thanks for your time, Srinivas._______________________________________________ </pre> Srinivas 2013-05-02T07:23:19 http://comments.gmane.org/gmane.ietf.nfsv4/12851 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without</pre> johnsonhammond1< at >hushmail.com 2013-04-27T17:33:54 http://comments.gmane.org/gmane.ietf.nfsv4/12819 <pre>Hi, I have a question regarding the expected behavior from an NFSv4 server when it exports some directory that requires a certain security flavor. For example lets say that a given server exports one path /a/b and requires all accesses to b to use krb5p. Should this server fail any request that does not use RPCSEC_GSS with privacy service (probably with NFS4ERR_WRONGSEC) ? Is it ok to allow PUTROOTFH, LOOKUP and GETATTR for the pseudefs entries even without the right kind of security service (e.g. authentication) in place? Thanks, Saul _______________________________________________ nfsv4 mailing list nfsv4&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/nfsv4 </pre> Saul Tamari 2013-04-18T16:39:09 http://comments.gmane.org/gmane.ietf.nfsv4/12812 <pre>Hi, I've stumbled on a case with a cthon byte range locking test running on a Linux client where I'm not sure what is the expected behavior. The sequence that I see is: 1. A file is opened and stateid si1 is returned 2. The same file is then exclusively locked using si1 and a new lock-owner, resulting in stateid si2 (which is totally different from si1) 3. The file is now being written using si1 (the stateid from step 1) Does an NFSv4 server need to allow the write on step 3 or fail it? Thanks, Saul _______________________________________________ nfsv4 mailing list nfsv4&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/nfsv4 </pre> Saul Tamari 2013-04-18T14:44:13 http://comments.gmane.org/gmane.ietf.nfsv4/12810 <pre>Hello Please review and send me comments on this requirements draft. Thanks --&gt;Andy A new version of I-D, draft-adamson-nfsv4-multi-domain-federated-fs-reqs-02.txt has been successfully submitted by William A. (Andy) Adamson and posted to the IETF repository. Filename: draft-adamson-nfsv4-multi-domain-federated-fs-reqs Revision: 02 Title: NFSv4 Multi-Domain FedFS Requirements Creation date: 2013-04-17 Group: Individual Submission Number of pages: 16 URL: http://www.ietf.org/internet-drafts/draft-adamson-nfsv4-multi-domain-federated-fs-reqs-02.txt Status: http://datatracker.ietf.org/doc/draft-adamson-nfsv4-multi-domain-federated-fs-reqs Htmlized: http://tools.ietf.org/html/draft-adamson-nfsv4-multi-domain-federated-fs-reqs-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-adamson-nfsv4-multi-domain-federated-fs-reqs-02 Abstract: This document describes constraints to the NFSv4.0 and NFSv4.1 protocols as well as the use of multi-domain capable file systems, name resolution services, and securit</pre> Andy Adamson 2013-04-17T18:30:00 http://comments.gmane.org/gmane.ietf.nfsv4/12806 <pre> Both RFC 1813 and 3530 specify: If the directory, to.dir, already contains an entry with the name, to.name, the source object must be compatible with the target: either both are non-directories or both are directories and the target must be empty. If compatible, the existing target is removed before the rename occurs. If they are not compatible or if the target is a directory but not empty, the server should return the error, NFS3ERR_EXIST. In contrast, man 2 rename indiates the following errors will result: EISDIR newpath is an existing directory, but oldpath is not a directtory. ENOTDIR A component used as a directory in oldpath or newpath is not, in fact, a directory. Or, oldpath is a directory, and newpath exists but is not a directory. EEXIST newpath is a non-empty directory, that is, contains entries other than "." and "..". I suppose my server should hew to the RFC, but it would be nice to just translate the return code from rename()... On the other hand, would a client really ge</pre> Frank S Filz 2013-04-17T00:10:59 http://comments.gmane.org/gmane.ietf.nfsv4/12798 <pre> All the NFS RFCs have the following text: If oldname and newname both refer to the same file (they might be hard links of each other), then RENAME should perform no action and return success. I wonder what the intent of this. It seems to imply that if a/foo and b/foo2 are hardlinks to the same file, that a rename a/foo -&gt; b/foo2 would result in no action, resulting in the directory entry a/foo still existing. When I try this operation on a local file system, the directory entry a/foo disappears and the link count goes from 2 to 1 when I ls -l b/foo2. Am I misinterpreting this text? Thanks Frank_______________________________________________ nfsv4 mailing list nfsv4&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/nfsv4 </pre> Frank S Filz 2013-04-16T16:15:00 http://comments.gmane.org/gmane.ietf.nfsv4/12793 <pre>Hi- After IESG review, the Security Considerations chapter of the FedFS ADMIN protocol draft now specifically requires that implementations of this protocol support GSSAPI security mechanisms. ADMIN protocol clients must use a service principal to establish a GSS context shared with the ADMIN server. To construct that principal, they need to know a priori the protocol's GSSAPI service name. This service name can be provided by a specification. This is typical practice to ensure interoperability between independent implementations. For NFS, RFC 2623, chapter 3.1 specifies the service name required for an NFS server that supports GSSAPI. In general, the form of that service name is specified in RFC 2724, chapter 4. An IANA registry exists that contains such names: http://www.iana.org/assignments/gssapi-service-names/gssapi-service-names.xml Here are several naive options for addressing this issue: 1. The FedFS ADMIN protocol always uses the server's host principal. 2. The FedFS ADMIN proto</pre> Chuck Lever 2013-04-12T16:42:51 http://comments.gmane.org/gmane.ietf.nfsv4/12792 <pre>Hi- The FedFS ADMIN RPC protocol provides a mechanism for provisioning NSDBs on remote fileservers. The operations it provides are FEDFS_SET_NSDB_PARAMS, FEDFS_GET_NSDB_PARAMS, and FEDFS_GET_LIMITED_NSDB_PARAMS. FEDFS_SET_NSDB_PARAMS specifies the name of an NSDB and the security mode to use when connecting to this NSDB. The fileserver connects to an NSDB in order to resolve a FedFS junction. The ADMIN protocol specification further says: [ Btw: When would a fileserver choose not to use these connection parameters? I think that SHOULD ought to be MUST, otherwise an administrator might specify a secure connection mode but get no security. ] There are two security modes defined in the protocol specification: FEDFS_SEC_NONE, which does not authenticate the LDAP server; and FEDFS_SEC_TLS, which uses START_TLS (RFC 4513) to authenticate the LDAP server. When FEDFS_SEC_TLS is specified with the FEDFS_SET_NSDB_PARAMS operation, an x.509v3 certificate chain is provided to the fileserver, wh</pre> Chuck Lever 2013-04-09T16:45:05 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.nfsv4