Subject: Re: [nfsv4] [PATCH] spec nits

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 8 Oct 2007 10:18:49 -0400

On Tue, Aug 28, 2007 at 03:38:28PM -0400, J. Bruce Fields wrote:
> These are just attempts to fix grammar problems, cut a few unnecessary
> words, and clarify slightly here or there.  Also some minor
> inconsistencies in terminology--describing posix/fcntl locks as
> "octet-range" seems a little pedantic, especially since "byte-range"
> seems to be the already-established usage, and ditto for "server
> reinitialization" vs. "server reboot"--but if I chose wrong then I could
> submit a patch to correct either one in the other direction.
> 
> There's (hopefully) no change in meaning anywhere.  (Though there were
> one or two places--such as in the definition of "Server" in 1.5--where I
> wasn't completely sure I understood the original.)
> 
> I can also send this as separate patches with comments on each if
> preferred.

Some of this got fixed in -14.  Thanks!  Some of it (e.g. the
"octet-range" byte language) still seems to be there.  I don't think
there were objections to this last time around, so here's an update to
apply against -14.

--b.

diff --git a/nfsv41_middle_core_infrastructure.xml b/nfsv41_middle_core_infrastructure.xml
index ce6425e..297f8eb 100755
--- a/nfsv41_middle_core_infrastructure.xml
+++ b/nfsv41_middle_core_infrastructure.xml
@@ -655,7 +655,7 @@
  </section> <!-- Client Identifiers -->
  <section anchor="Server Owners" title="Server Owners">
  <t>
-  The Server Owner is somewhat similar to a Client Owner
+  The Server Owner is similar to a Client Owner
   (<xref target="Client Identifiers" />), but unlike the
   Client Owner, there is no shorthand serverid.
   The Server Owner is defined in the following structure:
@@ -671,7 +671,7 @@ struct server_owner4 {
     </figure>
   </t>
   <t>
-   The Server Owner is returned in the results of
+   The Server Owner is returned from
    EXCHANGE_ID. When the so_major_id fields are the same in
    two EXCHANGE_ID results, the connections each EXCHANGE_ID
    are sent over can be assumed to address the same Server
@@ -740,9 +740,8 @@ struct server_owner4 {
    general, the client will not have to use either
    operation except during initial communication with the
    server or when the client crosses security policy boundaries at
-   the server.  It is possible that the server's policies
-   change during the client's interaction therefore
-   forcing the client to negotiate a new security tuple.
+   the server.  But the server's policies may also change at any
+   time and force the client to negotiate a new security tuple.
   </t>
   <t>
    Where the use of different security tuples would affect
@@ -1147,16 +1146,17 @@ struct server_owner4 {
   </t>
   <t>
    Principals with appropriate access rights can modify the
-   authorization on a file object via the SETATTR (<xref target="OP_SETATTR" />) operation. Four attributes
-   that affect access rights are: mode, owner, owner_group, and
-   acl.  See <xref target="file_attributes" />.
+   authorization on a file object via the SETATTR (<xref
+target="OP_SETATTR" />) operation. Attributes
+   that affect access rights include: mode, owner, owner_group, acl
+   dacl, and sacl.  See <xref target="file_attributes" />.
    </t>
   </section> <!-- Authorization -->
 
   <section anchor="Auditing" title="Auditing">
   <t>
    NFSv4.1 provides auditing on a per file object
-   basis, via the ACL attribute as described in <xref target="acl" />.
+   basis, via the acl and sacl attributes as described in <xref target="acl" />.
    It is outside the scope of this specification to specify
    audit log formats or management policies.
   </t>
@@ -1165,7 +1165,7 @@ struct server_owner4 {
   <section anchor="Intrusion Detection" title="Intrusion Detection">
   <t>
    NFSv4.1 provides alarm control on a per file object
-   basis, via the ACL attribute as described in <xref target="acl" />.
+   basis, via the acl and sacl attributes as described in <xref target="acl" />.
    Alarms may serve as the basis for intrusion detection.
    It is outside the scope of this specification to specify
    heuristics for detecting intrusion via alarms.
@@ -1396,8 +1396,8 @@ struct server_owner4 {
    state may be accessed using any of the sessions
    associated with that client's client ID, when
    connections are associated with those sessions. When
-   no connections are associated for any of the sessions
-   associated with the client ID for an extended time
+   no connections are associated with any of a client ID's
+   sessions for an extended time,
    such objects as locks, opens, delegations, layouts,
    etc. are subject to expiration.  The session serves as
    an object representing a means of access by a client to
@@ -1472,8 +1472,8 @@ struct server_owner4 {
    <t>
     Each client ID 
     (<xref target="Client Identifiers" />) can have
-    zero or more active sessions. A client ID, and a session
-    associated with it are required to perform file access in
+    zero or more active sessions. A client ID and associated
+    session are required to perform file access in
     NFSv4.1. Each time a session is used (whether by a client
     sending a request to the server, or the client replying
     to a callback request from the server), the state leased
@@ -1483,7 +1483,7 @@ struct server_owner4 {
    <t>
     State such as share reservations, locks, delegations,
     and layouts (<xref target="intro_locking" />) is tied to
-    the client ID. Client state is not tied to the sessions of the client ID.
+    the client ID. Client state is not tied to any individual session.
     Successive state changing operations from a given state
     owner MAY go over different sessions, provided the
     session is associated with the same client ID. A callback
@@ -1504,7 +1504,7 @@ struct server_owner4 {
   <section anchor="Channels" title="Channels">
   <t>
    A channel is not a connection. A channel represents the
-   direction ONC RPC requests are sent to.
+   direction ONC RPC requests are sent.
   </t>
   <t>
    Each session has one or two channels: the fore channel and the backchannel.
@@ -1583,7 +1583,7 @@ struct server_owner4 {
 
    </t>
    <t>
-    It is permissible for a connection of type of
+    It is permissible for a connection of one type of
     transport to be associated with the fore channel,
     and a connection of a different type to be associated
     with the backchannel.
diff --git a/nfsv41_middle_introduction.xml b/nfsv41_middle_introduction.xml
index e790215..5c90d66 100755
--- a/nfsv41_middle_introduction.xml
+++ b/nfsv41_middle_introduction.xml
@@ -288,7 +288,7 @@
     </section>
     <section anchor="intro_locking" title="Locking Facilities">
       <t>
-        As mentioned previously, NFS v4.1, is a single protocol which
+        As mentioned previously, NFS v4.1 is a single protocol which
         includes locking facilities.  These locking facilities 
         include support for many types of locks including a number
         of sorts of recallable locks.  Recallable locks such as
@@ -298,6 +298,10 @@
         via a callback request.  The assurances provided by 
         delegations allow more extensive caching to be done safely
         when circumstances allow it.
+      </t>
+      <t>
+        The types of locks are:
+      </t>
         <list style="symbols">
           <t>
             Share reservations as established by OPEN operations.
@@ -306,18 +310,18 @@
             Byte-range locks.
           </t>
           <t>
-            File delegations which are recallable locks that assure
+            File delegations, which are recallable locks that assure
             the holder that inconsistent opens and file changes cannot
             occur so long as the delegation is held.  
           </t>
           <t>
-            Directory delegations which are recallable delegations
+            Directory delegations, which are recallable locks
             that assure the holder that inconsistent directory 
             modifications cannot occur so long as the delegation 
             is held.
           </t>
           <t>
-            Layouts which are recallable objects that assure the
+            Layouts, which are recallable objects that assure the
             holder that direct access to the file data may be 
             performed directly by the client and that no change
             to the data's location inconsistent with that access
@@ -330,7 +334,7 @@
         single client-wide lease.  All requests made on sessions
         associated with the client renew that lease.  When leases
         are not promptly renewed locks are subject to revocation.
-        In the event of server re-initialization, clients have the
+        In the event of server reboot, clients have the
         opportunity to safely reclaim their locks within a special
         grace period.
       </t>
@@ -345,8 +349,8 @@
           The "client" is the entity that accesses the NFS server's
           resources.  The client may be an application which contains
           the logic to access the NFS server directly.  The client
-          may also be the traditional operating system client remote
-          file system services for a set of applications.
+          may also be the traditional operating system client that
+          provides remote file system services for a set of applications.
         <vspace blankLines='1' />
           A client is uniquely identified by a Client Owner.
         <vspace blankLines='1' />
@@ -385,8 +389,8 @@
           state about variable length leases across server failures.
         </t>
         <t hangText="Lock">
-          The term "lock" is used to refer to record (octet-range)
-          locks, share reservations, delegations or layouts unless
+          The term "lock" is used to refer to record (byte-range)
+          locks, share reservations, delegations, or layouts unless
           specifically stated otherwise.
         </t>
         <t hangText="Server">

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 10 Oct 2007 00:03:29 -0500

Bruce,

These changes have been integrated.

Spencer

On Oct 8, 2007, at 9:18 AM, J. Bruce Fields wrote:

> -   authorization on a file object via the SETATTR (<xref  
> target="OP_SETATTR" />) operation. Four attributes