Internet DRAFT - draft-haynes-nfsv4-minorversioning


NFSv4                                                          T. Haynes
Internet-Draft                                                    NetApp
Intended status: Standards Track                       November 08, 2013
Expires: May 12, 2014

                    Minor versioning Rules for NFSv4


   This document specifies the minor versioning rules for NFSv4.  It
   also specifices how those minor versioning rules may be modified.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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

   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 May 12, 2014.

Copyright Notice

   Copyright (c) 2013 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
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must

Haynes                    Expires May 12, 2014                  [Page 1]
Internet-Draft                    NFSv4                    November 2013

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Modifying the minor version rules . . . . . . . . . . . . . .   2
   4.  The minor versioning rules  . . . . . . . . . . . . . . . . .   3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .   6
   Appendix B.  RFC Editor Notes . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   To address the requirement of an NFS protocol that can evolve as the
   need arises, the Network File System (NFS) version 4 (NFSv4) protocol
   contains the rules and framework to allow for future minor changes or

   The base assumption with respect to minor versioning is that any
   future accepted minor version will be documented in one or more
   Standards Track RFCs.  Minor version 0 of the NFSv4 protocol is
   represented by [RFC3530], minor version 1 by [RFC5661], and minor
   version 2 by [NFSv42].  The COMPOUND (see Section 14.2 of [RFC3530])
   and CB_COMPOUND (see Section 15.2 of [RFC3530]) procedures support
   the encoding of the minor version being requested by the client.

2.  Terminology

   A basic familarity with the NFSv4 terminology is assumed in this
   document, the reader is pointed to [RFC3530].

3.  Modifying the minor version rules

   The minor versioning rules had been being maintained inside the
   various Standards Track RFCs, which had the impact of the minor
   versioning rules being modified as needed per release of the minor
   versions.  The rules for minor versions SHOULD stand outside the
   minor versions and be tracked by their own Standard Track RFCs.  As
   such, all modifications to the minor versioning rules MUST be
   documented not in the minor version documents, but in Standard Track

Haynes                    Expires May 12, 2014                  [Page 2]
Internet-Draft                    NFSv4                    November 2013

   RFCs which are focused entirely on the minor versioning rules

4.  The minor versioning rules

   The following items represent the basic rules for the development of
   minor versions.

   1.   Procedures are not added or deleted.

        To maintain the general Remote Procedure Call (RPC) model, NFSv4
        minor versions will not add to or delete procedures from the NFS

   2.   Minor versions may add operations to the COMPOUND and
        CB_COMPOUND procedures.

        The addition of operations to the COMPOUND and CB_COMPOUND
        procedures does not affect the RPC model.

        *  Minor versions may append attributes to the bitmap4 that
           represents sets of attributes and to the fattr4 that
           represents sets of attribute values.

           This allows for the expansion of the attribute model to allow
           for future growth or adaptation.

        *  Minor version X must append any new attributes after the last
           documented attribute.

           Since attribute results are specified as an opaque array of
           per-attribute, XDR-encoded results, the complexity of adding
           new attributes in the midst of the current definitions would
           be too burdensome.

   3.   Minor versions must not modify the structure of an existing
        operation's arguments or results.

        Again, the complexity of handling multiple structure definitions
        for a single operation is too burdensome.  New operations should
        be added instead of modifying existing structures for a minor

        This rule does not preclude the following adaptations in a minor

Haynes                    Expires May 12, 2014                  [Page 3]
Internet-Draft                    NFSv4                    November 2013

        *  adding bits to flag fields, such as new attributes to
           GETATTR's bitmap4 data type, and providing corresponding
           variants of opaque arrays, such as a notify4 used together
           with such bitmaps

        *  adding bits to existing attributes like Access Control Lists
           (ACL) that have flag words

        *  extending enumerated types (including NFS4ERR_*) with new

        *  adding cases to a switched union

   4.   Note that when adding new cases to a switched union, a minor
        version must not make new cases be REQUIRED.  While the
        encapsulating operation may be REQUIRED, the new cases (the
        specific arm of the discriminated union) is not.  The error code
        NFS4ERR_UNION_NOTSUPP is used to notify the client when the
        server does not support such a case.

   5.   Minor versions must not modify the structure of existing

   6.   Minor versions must not delete operations.

        This prevents the potential reuse of a particular operation
        "slot" in a future minor version.

   7.   Minor versions must not delete attributes.

   8.   Minor versions must not delete flag bits or enumeration values.

   9.   Minor versions may declare an operation MUST NOT be implemented.

        Specifying that an operation MUST NOT be implemented is
        equivalent to obsoleting an operation.  For the client, it means
        that the operation MUST NOT be sent to the server.  For the
        server, an NFS error can be returned as opposed to "dropping"
        the request as an XDR decode error.  This approach allows for
        the obsolescence of an operation while maintaining its structure
        so that a future minor version can reintroduce the operation.

        1.  Minor versions may declare that an attribute MUST NOT be

        2.  Minor versions may declare that a flag bit or enumeration
            value MUST NOT be implemented.

Haynes                    Expires May 12, 2014                  [Page 4]
Internet-Draft                    NFSv4                    November 2013

   10.  Minor versions may declare an operation to be OBSOLESCENT, which
        indicates an intention to remove the operation (i.e., make it
        MANDATORY TO NOT implement) in a subsequent minor version.  Such
        labeling is separate from the question of whether the operation
        is REQUIRED or RECOMMENDED or OPTIONAL in the current minor
        version.  An operation may be both REQUIRED for the given minor
        version and marked OBSOLESCENT, with the expectation that it
        will be MANDATORY TO NOT implement in the next (or other
        subsequent) minor version.

   11.  Note that the early notification of operation obsolescence is
        put in place to mitigate the effects of design and
        implementation mistakes, and to allow protocol development to
        adapt to unexpected changes in the pace of implementation.  Even
        if an operation is marked OBSOLESCENT in a given minor version,
        it may end up not being marked MANDATORY TO NOT implement in the
        next minor version.  In unusual circumstances, it might not be
        marked OBSOLESCENT in a subsequent minor version, and never
        become MANDATORY TO NOT implement.

   12.  Minor versions may downgrade features from REQUIRED to
        MANDATORY TO NOT implement.  Also, if a feature was marked as
        OBSOLESCENT in the prior minor version, it may be downgraded
        implement, or from REQUIRED to MANDATORY TO NOT implement.

   13.  Minor versions may upgrade features from OPTIONAL to
        RECOMMENDED, or RECOMMENDED to REQUIRED.  Also, if a feature was
        marked as OBSOLESCENT in the prior minor version, it may be
        upgraded to not be OBSOLESCENT.

   14.  A client and server that support minor version X SHOULD support
        minor versions 0 through X-1 as well.

   15.  Except for infrastructural changes, a minor version must not
        introduce REQUIRED new features.

        This rule allows for the introduction of new functionality and
        forces the use of implementation experience before designating a
        feature as REQUIRED.  On the other hand, some classes of
        features are infrastructural and have broad effects.  Allowing
        infrastructural features to be RECOMMENDED or OPTIONAL
        complicates implementation of the minor version.

Haynes                    Expires May 12, 2014                  [Page 5]
Internet-Draft                    NFSv4                    November 2013

   16.  A client MUST NOT attempt to use a stateid, filehandle, or
        similar returned object from the COMPOUND procedure with minor
        version X for another COMPOUND procedure with minor version Y,
        where X != Y.

5.  Security Considerations

   There are no security considerations in this document.

6.  IANA Considerations

   There are no IANA considerations in this document.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

   [RFC3530]  Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
              Beame, C., Eisler, M., and D. Noveck, "Network File System
              (NFS) version 4 Protocol", RFC 3530, April 2003.

   [RFC5661]  Shepler, S., Eisler, M., and D. Noveck, "Network File
              System (NFS) Version 4 Minor Version 1 Protocol", RFC
              5661, January 2010.

7.2.  Informative References

   [NFSv42]   Haynes, T., "NFS Version 4 Minor Version 2", draft-ietf-
              nfsv4-minorversion2-20 (Work In Progress), August 2013.

Appendix A.  Acknowledgments

Appendix B.  RFC Editor Notes

   [RFC Editor: please remove this section prior to publishing this
   document as an RFC]

   [RFC Editor: prior to publishing this document as an RFC, please
   replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the
   RFC number of this document]

Author's Address

Haynes                    Expires May 12, 2014                  [Page 6]
Internet-Draft                    NFSv4                    November 2013

   Thomas Haynes
   495 E Java Dr
   Sunnyvale, CA  95054

   Phone: +1 408 419 3018

Haynes                    Expires May 12, 2014                  [Page 7]