Internet DRAFT - draft-eisler-nfsv4-impid

draft-eisler-nfsv4-impid




   Network Working Group
   Internet Draft                                             M. Eisler
   Document: draft-eisler-nfsv4-impid-00.txt    Network Appliance, Inc.
   Expires: February 2006                                   August 2005


                   Identifying Implementations in NFSv4


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 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/1id-abstracts.html

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


Abstract

   NFSv4.0 has no method for allowing clients and servers to provide to
   each other their implementation identities. An implementation
   identity might contain the name of the software that embodies the
   NFSv4 client or server, and the version number of the software. This
   proposal describes how a future minor version of NFSv4.0 could allow
   clients and servers to exchange implementation identities.



Conventions used in this document



Eisler                                                               1

Identifying Implementations in NFSv4                       August 2005


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [i].

Table of Contents

   1. Introduction...................................................2
   2. New Operation: EXCH_IMPL_IDENTS4...............................2
   3. Alternative: New Attributes....................................4
   4. Security Considerations........................................5
   5. IANA Considerations............................................5
   6. References.....................................................5
   7. Acknowledgments................................................5
   8. Author's Addresses.............................................5
   9. Copyright Notice...............................................5


1.   Introduction

   In the event of an interoperability problem, knowing information
   about the implementation of the peer can be very useful. Even when
   there are not interoperability problems, understanding what
   implementations are communication to ones own NFS client and server
   can be useful for implementers and users. For example, if an NFSv4
   server implementer knew that just 1% of clients connecting to his
   server were made by XYZ, Ltd., and 99% by ABC, Inc., then he could
   allocate his training budget for customer support staff to be
   weighted more toward understanding the intricacies of ABCÆs NFSv4
   client.

   There are two alternative approaches presented here:
     . A new operation
     . A new attribute
   The intent is that only one approach will be specified in a future
   minor version.


2.   New Operation: EXCH_IMPL_IDENTS4

   SYNOPSIS

   clientid, ImplDomainName, ImplName, ImplDate ->
      ImplDomainName, ImplName, ImplDate

   ARGUMENT

     struct nfs_impl_id {
      utf8str_cis  nii_domain4; /* domain name of implementer */
      utf8str_cs   nii_name; /* product name of implementation */


Eisler                                                               2

Identifying Implementations in NFSv4                       August 2005


      nfstime4     nii_date; /* date of implementation */

     }

     struct EXCH_IMPL_IDENTS4args {
       clientid4          eii_clientid4;
       struct nfs_impl_id eii_clnt_impl;
     };

   RESULT

     union EXCH_IMPL_IDENTS4res (nfsstat4 status) {
         case NFS4_OK:
          nfs_impl_id niiok4;

         default:
          void;
     }

   DESCRIPTION

     The NFSv4 client and server use the EXCH_IMPL_IDENTS4 operation to
     exchange their implementation identities.

     EXCH_IMPL_IDENTS4 requires an established clientid. This is so
     diagnostic software on the client and server can display the list
     of NFSv4 peers by clientid. It also allows a client to update its
     implementation identifier, and similarly allows the server to
     update its implementation identifier if the client wants an update.

     The client and server exchange a value of type nfs_impl_id. The
     nii_domain4 field is just the DNS domain name that the implementer
     is associated with. For example, the Linux client might supply
     kernel.org. The Network Appliance server might supply
     netapp.com. The nii_name field is the product name of the
     implementation and is completely free form. Implementations are
     encouraged to use the from form nii_name string to distinguish
     machine architecture, machine platforms, revisions, versions, and
     patch levels of the same implementation., implementations are
     encouraged to provide as much detail as possible. For example, a
     Solaris client and server might send a string equal to the output
     of its "uname -a" command. The nii_date field is the timestamp of
     when the software instance was published or built.

   IMPLEMENTATION
     The intent is for NFSv4 clients and servers to record the
     nfs_impl_id values they receive, and allow users, and optionally
     vendors to access the set of received nfs_impl_id values. This way,
     an implementation supporting an automated customer support system


Eisler                                                               3

Identifying Implementations in NFSv4                       August 2005


     that reports problems to the vendor as they occur, can send the
     nfs_impl_id values in the reports.

     An NFSv4 client or server MUST NOT interpret the implementation
     identity information sent to it by a peer (respectively), in a way
     that affects interoperational behavior of the implementation. The
     reason is the if clients and servers did such a thing, they might
     use fewer capabilities of the protocol than the peer can support,
     or the client and server might refuse to interoperate. This
     unhealthy situation exists with http clients and servers today.
     Because it is likely some implementations will violate the protocol
     specification and interpret the identity information, the following
     is also required of NFSv4 implementations:

       . Implementations MUST allow the EXCH_IMPL_IDENTS4 operation to
          be disabled.
       . Implementations MUST allow the users of the NFSv4 client and
          server to set the contents of the sent nfs_impl_id structure
          to any value.
   ERRORS

     NFS4ERR_STALE_CLIENTID
     NFS4ERR_NAMETOOLONG
     NFS4ERR_NOTSUPP
     NFS4ERR_ACCESS



3.   Alternative: New Attributes

   If preferred, instead of a new operation, two new attributes,
   send_impl_id and recv_impl_id are defined. Both are placed in the per
   server classification.

     Name          #        Data Type             Access     Description
     send_impl_id  56       EXCH_IMPL_IDENTS4args WRITE      Via SETATTR,
                                                               the client
                                                               tells the
                                                               server its
                                                               implementation
                                                               identity.

     recv_impl_id  57       nfs_impl_id           READ       Via GETATTR,
                                                               the client
                                                               determines
                                                               from the
                                                               server its
                                                               implementation



Eisler                                                               4

Identifying Implementations in NFSv4                       August 2005


     Name          #        Data Type             Access     Description
                                                               identity.


   Both send_impl_id and recv_impl_id are RECOMMENDED. However, if an
   NFSv4 server implements either of send_impl_id or recv_impl_id, it
   MUST implement them both.

4.   Security Considerations

   NFSv4 servers MUST check the principal used to send client
   implementation identify against the principal used to establish the
   clientid via SETCLIENTID. If the principal and security flavor do not
   match, then the error NFS4ERR_ACCESS MUST be returned.

5.   IANA Considerations

   There are no IANA considerations.

6.   References

   i  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997



7.   Acknowledgments

   Thanks to Mario Wurzl for sanity checking the problem this proposal
   attempts to solve.


8.   Author's Addresses

   Mike Eisler
   Network Appliance, Inc.

   5765 Chase Point Circle
   Colorado Springs, CO  80919
   United States of America

   Phone: 1-719-599-9026
   Email: email2mre-ietf@yahoo.com

9.   Copyright Notice

   Copyright (C) The Internet Society (2005).




Eisler                                                               5

Identifying Implementations in NFSv4                       August 2005


   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.








































Eisler                                                               6