--- 1/draft-ietf-nfsv4-rfc1832bis-01.txt	2006-02-05 00:48:32.000000000 +0100
+++ 2/draft-ietf-nfsv4-rfc1832bis-02.txt	2006-02-05 00:48:32.000000000 +0100
@@ -1,15 +1,15 @@
 
 Network Working Group                                          M. Eisler
 Internet-Draft                                                    Editor
-Document: draft-ietf-nfsv4-rfc1832bis-01.txt     Network Appliance, Inc.
-                                                                May 2003
+Document: draft-ietf-nfsv4-rfc1832bis-02.txt     Network Appliance, Inc.
+                                                            October 2003
 
                XDR: External Data Representation Standard
 
 Status of this Memo
 
    This document is an Internet-Draft and is in full conformance
    with all provisions of Section 10 of RFC2026.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
@@ -73,21 +73,21 @@
    12.  NORMATIVE REFERENCES  . . . . . . . . . . . . . . . . . . .  23
    13.  INFORMATIVE REFERENCES  . . . . . . . . . . . . . . . . . .  23
    14.  Editor's Address  . . . . . . . . . . . . . . . . . . . . .  24
    15.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . .  24
    16.  IPR Notices . . . . . . . . . . . . . . . . . . . . . . . .  24
    17.  Copyright Notice  . . . . . . . . . . . . . . . . . . . . .  24
 
 1.  Changes from RFC1832
 
    This document makes no technical changes to RFC1832 and is published
-   for the purpose noting IANA considerations and distinguishing
+   for the purpose of noting IANA considerations and distinguishing
    normative from informative references.
 
 2.  INTRODUCTION
 
    XDR is a standard for the description and encoding of data.  It is
    useful for transferring data between different computer
    architectures, and has been used to communicate data between such
    diverse machines as the SUN WORKSTATION*, VAX*, IBM-PC*, and Cray*.
    XDR fits into the ISO presentation layer, and is roughly analogous in
    purpose to X.409, ISO Abstract Syntax Notation.  The major difference
@@ -882,22 +882,22 @@
            type-def
          | constant-def
 
       specification:
            definition *
 
 6.4.  Syntax Notes
 
    (1) The following are keywords and cannot be used as identifiers:
    "bool", "case", "const", "default", "double", "quadruple", "enum",
-   "float", "hyper", "opaque", "string", "struct", "switch", "typedef",
-   "union", "unsigned" and "void".
+   "float", "hyper", "int", "opaque", "string", "struct", "switch",
+   "typedef", "union", "unsigned" and "void".
 
    (2) Only unsigned constants may be used as size specifications for
    arrays.  If an identifier is used, it must have been declared
    previously as an unsigned constant in a "const" definition.
 
    (3) Constant and type identifiers within the scope of a specification
    are in the same name space and must be declared uniquely within this
    scope.
 
    (4) Similarly, variable names must be unique within the scope of
@@ -1100,21 +1100,22 @@
       Phone: 719-599-9026
       EMail: mike@eisler.com
 
 15.  Acknowledgements
 
    Bob Lyon was Sun's visible force behind ONC RPC in the 1980s.  Sun
    Microsystems, Inc. is listed as the author of RFC1014, which RFC1832
    was heavily derived from. Raj Srinivasan in turn edited RFC1014 into
    RFC1832. Raj and the rest of the old ONC RPC working group produced
    RFC1832 from which this document is derived.  Mike Eisler and Bill
-   Janssen submitted the implementation reports for this standard.
+   Janssen submitted the implementation reports for this standard. Kevin
+   Coffman and Benny Halevy reviewed this document and gave feedback.
 
 16.  IPR Notices
 
    The IETF takes no position regarding the validity or scope of any
    intellectual property or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; neither does it represent that it
    has made any effort to identify any such rights.  Information on the
    IETF's procedures with respect to rights in standards-track and