--- 1/draft-ietf-nfsv4-flex-files-01.txt	2014-10-07 08:14:58.060549852 -0700
+++ 2/draft-ietf-nfsv4-flex-files-02.txt	2014-10-07 08:14:58.108551036 -0700
@@ -1,18 +1,18 @@
 
 NFSv4                                                          B. Halevy
 Internet-Draft                                                 T. Haynes
 Intended status: Informational                              Primary Data
-Expires: March 8, 2015                                September 04, 2014
+Expires: April 10, 2015                                 October 07, 2014
 
                 Parallel NFS (pNFS) Flexible File Layout
-                   draft-ietf-nfsv4-flex-files-01.txt
+                   draft-ietf-nfsv4-flex-files-02.txt
 
 Abstract
 
    The Parallel Network File System (pNFS) allows a separation between
    the metadata and data for a file.  The metadata file access is
    handled via Network File System version 4 (NFSv4) minor version 1
    (NFSv4.1) and the data file access is specific to the protocol being
    used between the client and storage device.  The client is informed
    by the metadata server as to which protocol to use via a Layout Type.
    The Flexible File Layout Type is defined in this document as an
@@ -27,21 +27,21 @@
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.
 
    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."
 
-   This Internet-Draft will expire on March 8, 2015.
+   This Internet-Draft will expire on April 10, 2015.
 
 Copyright Notice
 
    Copyright (c) 2014 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
@@ -492,37 +492,40 @@
    the data consist of exact replicas.
 
 5.  Flexible File Layout Type
 
    The layout4 type is defined in [RFC5662] as follows:
 
        enum layouttype4 {
            LAYOUT4_NFSV4_1_FILES   = 1,
            LAYOUT4_OSD2_OBJECTS    = 2,
            LAYOUT4_BLOCK_VOLUME    = 3,
-           LAYOUT4_FLEX_FILES      = 4
+           LAYOUT4_FLEX_FILES      = 0x80000004
    [[RFC Editor: please modify the LAYOUT4_FLEX_FILES
      to be the layouttype assigned by IANA]]
        };
 
        struct layout_content4 {
            layouttype4             loc_type;
            opaque                  loc_body<>;
        };
 
        struct layout4 {
            offset4                 lo_offset;
            length4                 lo_length;
            layoutiomode4           lo_iomode;
            layout_content4         lo_content;
        };
 
+   [[AI10: Remember, using experimental version number to track changes
+   to the XDR via LAYOUT4_FLEX_FILES!  --TH]]
+
    This document defines structure associated with the layouttype4 value
    LAYOUT4_FLEX_FILES.  [RFC5661] specifies the loc_body structure as an
    XDR type "opaque".  The opaque layout is uninterpreted by the generic
    pNFS client layers, but obviously must be interpreted by the Flexible
    File Layout Type implementation.  This section defines the structure
    of this opaque value, ff_layout4.
 
 5.1.  ff_layout4
 
    /// struct ff_data_server4 {
@@ -549,24 +552,26 @@
    copies of the data file.  This mirroring protects against loss of
    data files.
 
    It is possible that the file is concatenated from more than one
    layout segment.  Each layout segment MAY represent different striping
    parameters, applying respectively only to the layout segment byte
    range.
 
    The ffl_stripe_unit field is the stripe unit size in use for the
    current layout segment.  The number of stripes is given inside each
-   mirror by the number of elements in ffm_data_servers.  The only
-   supported mapping scheme is sparse and is detailed in Section 6.
-   Note that there is an assumption here that both the stripe unit size
-   and the number of of stripes is the same across all mirrors.
+   mirror by the number of elements in ffm_data_servers.  If the number
+   of stripes is one, then the value for ffl_stripe_unit MUST default to
+   zero.  The only supported mapping scheme is sparse and is detailed in
+   Section 6.  Note that there is an assumption here that both the
+   stripe unit size and the number of of stripes is the same across all
+   mirrors.
 
    The ffl_mirrors field is the array of mirrored storage devices which
    provide the storage for the current stripe, see Figure 1.
 
                       +-----------+
                       |           |
                       |           |
                       |   File    |
                       |           |
                       |           |