Subject: [nfsv4] I-D Action: draft-ietf-nfsv4-rfc3530bis-34.txt

From: [email-masked]
Date: Mon, 10 Nov 2014 21:59:07 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network File System Version 4 Working Group of the IETF.

        Title           : Network File System (NFS) Version 4 Protocol
        Authors         : Thomas Haynes
                          David Noveck
	Filename        : draft-ietf-nfsv4-rfc3530bis-34.txt
	Pages           : 297
	Date            : 2014-11-10

Abstract:
   The Network File System (NFS) version 4 is a distributed file system
   protocol which builds on the heritage of NFS protocol version 2, RFC
   1094, and version 3, RFC 1813.  Unlike earlier versions, the NFS
   version 4 protocol supports traditional file access while integrating
   support for file locking and the mount protocol.  In addition,
   support for strong security (and its negotiation), compound
   operations, client caching, and internationalization have been added.
   Of course, attention has been applied to making NFS version 4 operate
   well in an Internet environment.

   This document, together with the companion XDR description document,
   RFCNFSv4XDR, obsoletes RFC 3530 as the definition of the NFS version
   4 protocol.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc3530bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-nfsv4-rfc3530bis-34

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-rfc3530bis-34

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Marcel Telka <[email-masked]>
Date: Tue, 11 Nov 2014 08:42:15 +0100

Minor nits:

Missing period at the end of the sentence:

	1.6.  Changes between RFC 3010 and RFC3530

	   The definition of the NFSv4 protocol in [RFC3530] replaced and
	   obsoleted the definition present in [RFC3010]  While portions of the
							^
	   two documents remained the same, there were substantive changes in

Duplicate "can be":
	
	5.4.  Classification of Attributes

	   Each of attributes accessed using SETATTR and GETATTR (i.e., REQUIRED
	   an RECOMMENDED attributes) can be can be classified in one of three
	   categories:

Missing period at the end of the sentence:

	6.3.1.2.  Client Considerations

	   Clients SHOULD NOT do their own access checks based on their
	   interpretation the ACL, but rather use the OPEN and ACCESS operations
	   to do access checks.  This allows the client to act on the results of
	   having the server determine whether or not access should be granted
	   based on its interpretation of the ACL.

	   Clients must be aware of situations in which an object's ACL will
	   define a certain access even though the server will not have adequate
	   information to enforce it.  For example, the server has no way of
	   determining whether a particular OPEN reflects a user's open for read
	   access, or is done as part of executing the file in question In such
								       ^
	   situations, the client needs to do its part in the enforcement of
	   access as defined by the ACL.  To do this, the client will send the

On Mon, Nov 10, 2014 at 09:59:07PM -0800, [email-masked] wrote:
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

-- 
+-------------------------------------------+
| Marcel Telka   e-mail:   [email-masked]  |
|                homepage: http://telka.sk/ |
|                jabber:   [email-masked] |
+-------------------------------------------+

---

From: Marcel Telka <[email-masked]>
Date: Tue, 11 Nov 2014 16:48:50 +0100

One more finding:  We reference Windows 2000 two times in the RFC3530bis,
but Windows 2000 is more than 4 years EOLed now[1].  We should "upgrade".

5.8.2.5.  Attribute 18: chown_restricted

   If TRUE, the server will reject any request to change either the
   owner or the group associated with a file if the caller is not a
   privileged user (for example, "root" in UNIX operating environments
   or in Windows 2000, the "Take Ownership" privilege).

...

   LOCK operations are subject to permission checks and to checks
   against the access type of the associated file.  However, the
   specific right and modes required for various type of locks, reflect
   the semantics of the server-exported file system, and are not
   specified by the protocol.  For example, Windows 2000 allows a write
   lock of a file open for READ, while a POSIX-compliant system does
   not.

[1] http://en.wikipedia.org/wiki/Windows_2000

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 12 Nov 2014 13:38:44 -0500

> but Windows 2000 is more than 4 years EOLed now[1].  We should "upgrade".

Why, and to what?  As just an example it seems OK to me as is.

--b.

---

From: Tom Haynes <[email-masked]>
Date: Wed, 12 Nov 2014 14:15:59 -0800

Thanks, fixed.

> On Nov 10, 2014, at 11:42 PM, Marcel Telka <[email-masked]> wrote:
> 
> Minor nits:
>