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
