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