NFSV4 Editor

---

This site originally created by Spencer Sheple in 2006, was used by the editor for the NFSv4 minor version 1 internet draft as a method of distributing content and issue tracking. The content below is from the site's 2006-2008 archived pages.

The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. 

The Internet Engineering Task Force (IETF) develops and promotes voluntary Internet standards, in particular the standards that comprise the Internet protocol suite (TCP/IP). It is an open standards organization, with no formal membership or membership requirements. All participants and managers are volunteers, though their work is usually funded by their employers or sponsors.

The IETF started out as an activity supported by the U.S. federal government, but since 1993 it has operated as a standards development function under the auspices of the Internet Society, an international membership-based non-profit organization.

For network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture this website would be reasonably easy to comprehend, unlike people like myself. I was wondering if a developer found something useful on this site if they could just copy the code and start using it. I have a friend who does a lot of web site development so I put the question to him. He suspected it was ok since all the code here was already made public and are part of established standards. I could tell he did not want to commit to approving the use without qualifications. But I think he's correct, or why else would these protocols be so available? The firm that handles my affiliate online casino site's search engine optimization probably have some coders who could look at the the code below and read it like an interesting puzzle. I find it fascinating how a page's code which is incomprehensible to me actually renders into a great looking web page. Most people just don't even think about how something is created on the web.

I look at the online casino sites that offer slots for US players as well as a myriad of other casino games and realize that all the glitz, bells and whistles of the casino games are created with code. When I have peeked at the source code on my affiliate casino site, I might as well be looking at a page written in Chinese characters.

But the men and women who are part of the Internet Engineering Task Force (IETF) which is a large open international community, create similar code everyday. Kudos to them who keep our Internet running smoothly.

I am going to stick to enjoying playing my favorite slot games, check out the weekly slot promos my webmaster puts up each Thursday, win some money, lose some money, but ultimately enjoy myself like thousands, - more likely probably millions of online casino players or punters, if you are from Australia, do every day. I'll just leave the coding to other people who have a head for it.

 

---

+++

2006 Session Changes for Trunking
Proposal to address Issue 30

+++

NFSv4  
Internet-Draft 

Editors: S. Shepler | D.Noveck | M. Eisler
Intended status: Standards Track   
Expires: June 20, 2006

December 22, 2006

 

 

NFSv4 Minor Version 1

draft-ietf-nfsv4-minorversion1-03.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups.  Note that other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed athttp://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 22, 2006.

Copyright Notice: Copyright (C) The Internet Society (2006).

Abstract

   This Internet-Draft describes the NFSv4 minor version 1 protocol extensions.  These most significant of these extensions are commonly called: Sessions, Directory Delegations, and parallel NFS or pNFS

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

Shepler   Expires December 22, 2006               [Page 1]

Internet-Draft  NFSv4 Minor Version 1                June 2006

 

Shepler                 Expires December 22, 2006               [Page 8]

Internet-Draft            NFSv4 Minor Version 1                June 2006

 

1.  Protocol Data Types

   The syntax and semantics to describe the data types of the NFS
   version 4 protocol are defined in the XDR RFC1832 [2] and RPC RFC1831
   [3] documents.  The next sections build upon the XDR data types to
   define types and structures specific to this protocol.

1.1.  Basic Data Types

                   These are the base NFSv4 data types.

   +---------------+---------------------------------------------------+
   | Data Type     | Definition                                        |
   +---------------+---------------------------------------------------+
   | int32_t       | typedef int int32_t;                              |
   | uint32_t      | typedef unsigned int uint32_t;                    |
   | int64_t       | typedef hyper int64_t;                            |
   | uint64_t      | typedef unsigned hyper uint64_t;                  |
   | attrlist4     | typedef opaque attrlist4<>;                       |
   |               | Used for file/directory attributes                |
   | bitmap4       | typedef uint32_t bitmap4<>;                       |
   |               | Used in attribute array encoding.                 |
   | changeid4     | typedef uint64_t changeid4;                       |
   |               | Used in definition of change_info                 |
   | clientid4     | typedef uint64_t clientid4;                       |
   |               | Shorthand reference to client identification      |
   | component4    | typedef utf8str_cs component4;                    |
   |               | Represents path name components                   |
   | count4        | typedef uint32_t count4;                          |
   |               | Various count parameters (READ, WRITE, COMMIT)    |
   | length4       | typedef uint64_t length4;                         |
   |               | Describes LOCK lengths                            |
   | linktext4     | typedef utf8str_cs linktext4;                     |
   |               | Symbolic link contents                            |
   | mode4         | typedef uint32_t mode4;                           |
   |               | Mode attribute data type                          |
   | nfs_cookie4   | typedef uint64_t nfs_cookie4;                     |
   |               | Opaque cookie value for READDIR                   |
   | nfs_fh4       | typedef opaque nfs_fh4               |
   |               | Filehandle definition; NFS4_FHSIZE is defined as  |
   |               | 128                                               |
   | nfs_ftype4    | enum nfs_ftype4;                                  |
   |               | Various defined file types                        |
   | nfsstat4      | enum nfsstat4;                                    |
   |               | Return value for operations                       |
   | offset4       | typedef uint64_t offset4;                         |
   |               | Various offset designations (READ, WRITE, LOCK,   |
   |               | COMMIT)                                           |

 

Shepler                 Expires December 22, 2006               [Page 9]

Internet-Draft            NFSv4 Minor Version 1                June 2006

 

   | pathname4     | typedef component4 pathname4<>;                   |
   |               | Represents path name for fs_locations             |
   | qop4          | typedef uint32_t qop4;                            |
   |               | Quality of protection designation in SECINFO      |
   | sec_oid4      | typedef opaque sec_oid4<>;                        |
   |               | Security Object Identifier The sec_oid4 data type |
   |               | is not really opaque. Instead contains an ASN.1   |
   |               | OBJECT IDENTIFIER as used by GSS-API in the       |
   |               | mech_type argument to GSS_Init_sec_context. See   |
   |               | RFC2743 [4] for details.                          |
   | seqid4        | typedef uint32_t seqid4;                          |
   |               | Sequence identifier used for file locking         |
   | utf8string    | typedef opaque utf8string<>;                      |
   |               | UTF-8 encoding for strings                        |
   | utf8str_cis   | typedef opaque utf8str_cis;                       |
   |               | Case-insensitive UTF-8 string                     |
   | utf8str_cs    | typedef opaque utf8str_cs;                        |
   |               | Case-sensitive UTF-8 string                       |
   | utf8str_mixed | typedef opaque utf8str_mixed;                     |
   |               | UTF-8 strings with a case sensitive prefix and a  |
   |               | case insensitive suffix.                          |
   | verifier4     | typedef opaque verifier4[NFS4_VERIFIER_SIZE];     |
   |               | Verifier used for various operations (COMMIT,     |
   |               | CREATE, OPEN, READDIR, SETCLIENTID,               |
   |               | SETCLIENTID_CONFIRM, WRITE) NFS4_VERIFIER_SIZE is |
   |               | defined as 8.                                     |
   +---------------+---------------------------------------------------+

                          End of Base Data Types

                                  Table 1

1.2.  Structured Data Types

1.2.1.  nfstime4

   struct nfstime4 {
       int64_t seconds;
       uint32_t nseconds;
   }

   The nfstime4 structure gives the number of seconds and nanoseconds since midnight or 0 hour January 1, 1970 Coordinated Universal Time(UTC).  Values greater than zero for the seconds field denote dates after the 0 hour January 1, 1970.  Values less than zero for the seconds field denote dates before the 0 hour January 1, 1970.  In both cases, the nseconds field is to be added to the seconds field for the final time representation.  For example, if the time to be

+++

Shepler
Expires December 22, 2006
[Page 10]

Internet-Draft represented is one-half second before 0 hour January 1, 1970, the seconds field would have a value of negative one (-1) and the nseconds fields would have a value of one-half second (500000000).
Values greater than 999,999,999 for nseconds are considered invalid.

his data type is used to pass time and date information.  A server converts to and from its local representation of time when processing time values, preserving as much accuracy as possible.  If the precision of timestamps stored for a filesystem object is less than defined, loss of precision can occur.  An adjunct time maintenance protocol is recommended to reduce client and server time skew.

1.2.2.  time_how4

   enum time_how4 {
       SET_TO_SERVER_TIME4 = 0,
       SET_TO_CLIENT_TIME4 = 1
   };

1.2.3.  settime4

   union settime4 switch (time_how4 set_it) {
       case SET_TO_CLIENT_TIME4:
           nfstime4       time;
       default:
           void;
   };

   The above definitions are used as the attribute definitions to set
   time values.  If set_it is SET_TO_SERVER_TIME4, then the server uses
   its local representation of time for the time value.

1.2.4.  specdata4

   struct specdata4 {
       uint32_t specdata1; /* major device number */
       uint32_t specdata2; /* minor device number */
   };

   This data type represents additional information for the device file
   types NF4CHR and NF4BLK.

1.2.5.  fsid4

   struct fsid4 {
       uint64_t        major;
       uint64_t        minor;
   };

+++

Shepler                 Expires December 22, 2006              [Page 11]

Internet-Draft            NFSv4 Minor Version 1                June 2006

 

1.2.6.  fs_location4

   struct fs_location4 {
       utf8str_cis    server<>;
       pathname4     rootpath;
   };

1.2.7.  fs_locations4

   struct fs_locations4 {
       pathname4     fs_root;
       fs_location4  locations<>;
   };

   The fs_location4 and fs_locations4 data types are used for the
   fs_locations recommended attribute which is used for migration and
   replication support.

1.2.8.  fattr4

   struct fattr4 {
       bitmap4       attrmask;
       attrlist4     attr_vals;
   };

   The fattr4 structure is used to represent file and directory
   attributes.

   The bitmap is a counted array of 32 bit integers used to contain bit
   values.  The position of the integer in the array that contains bit n
   can be computed from the expression (n / 32) and its bit within that
   integer is (n mod 32).

 

   0            1
   +-----------+-----------+-----------+--
   |  count    | 31  ..  0 | 63  .. 32 |
   +-----------+-----------+-----------+--

1.2.9.  change_info4

   struct change_info4 {
       bool          atomic;
       changeid4     before;
       changeid4     after;
   };

   This structure is used with the CREATE, LINK, REMOVE, RENAME

+++

Shepler                 Expires December 22, 2006              [Page 12]

Internet-Draft            NFSv4 Minor Version 1                June 2006

 

   operations to let the client know the value of the change attribute
   for the directory in which the target filesystem object resides.

1.2.10.  clientaddr4

   struct clientaddr4 {
       /* see struct rpcb in RFC1833 */
       string r_netid<>;    /* network id */
       string r_addr<>;     /* universal address */
   };

   The clientaddr4 structure is used as part of the SETCLIENTID
   operation to either specify the address of the client that is using a
   clientid or as part of the callback registration.  The r_netid and
   r_addr fields are specified in RFC1833 [9], but they are
   underspecified in RFC1833 [9] as far as what they should look like
   for specific protocols.

   For TCP over IPv4 and for UDP over IPv4, the format of r_addr is the
   US-ASCII string:

   h1.h2.h3.h4.p1.p2

   The prefix, "h1.h2.h3.h4", is the standard textual form for
   representing an IPv4 address, which is always four octets long.
   Assuming big-endian ordering, h1, h2, h3, and h4, are respectively,
   the first through fourth octets each converted to ASCII-decimal.
   Assuming big-endian ordering, p1 and p2 are, respectively, the first
   and second octets each converted to ASCII-decimal.  For example, if a
   host, in big-endian order, has an address of 0x0A010307 and there is
   a service listening on, in big endian order, port 0x020F (decimal
   527), then complete universal address is "10.1.3.7.2.15".

   For TCP over IPv4 the value of r_netid is the string "tcp".  For UDP
   over IPv4 the value of r_netid is the string "udp".

   For TCP over IPv6 and for UDP over IPv6, the format of r_addr is the
   US-ASCII string:

   x1:x2:x3:x4:x5:x6:x7:x8.p1.p2

   The suffix "p1.p2" is the service port, and is computed the same way
   as with universal addresses for TCP and UDP over IPv4.  The prefix,
   "x1:x2:x3:x4:x5:x6:x7:x8", is the standard textual form for
   representing an IPv6 address as defined in Section 2.2 of RFC1884
   [5].  Additionally, the two alternative forms specified in Section
   2.2 of RFC1884 [5] are also acceptable.

+++

Shepler                 Expires December 22, 2006              [Page 13]

Internet-Draft            NFSv4 Minor Version 1                June 2006

 

   For TCP over IPv6 the value of r_netid is the string "tcp6".  For UDP
   over IPv6 the value of r_netid is the string "udp6".

1.2.11.  cb_client4

   struct cb_client4 {
       unsigned int  cb_program;
       clientaddr4   cb_location;
   };

   This structure is used by the client to inform the server of its call
   back address; includes the program number and client address.

1.2.12.  nfs_client_id4

   struct nfs_client_id4 {
       verifier4     verifier;
       opaque        id
   };

   This structure is part of the arguments to the SETCLIENTID operation.
   NFS4_OPAQUE_LIMIT is defined as 1024.

1.2.13.  open_owner4

   struct open_owner4 {
       clientid4     clientid;
       opaque        owner
   };

   This structure is used to identify the owner of open state.
   NFS4_OPAQUE_LIMIT is defined as 1024.

1.2.14.  lock_owner4

   struct lock_owner4 {
       clientid4     clientid;
       opaque        owner
   };

   This structure is used to identify the owner of file locking state.
   NFS4_OPAQUE_LIMIT is defined as 1024.

---

---