Implementation Guide for Referrals in NFSv4
draft-ietf-nfsv4-referrals-00
| Document | Type | Expired Internet-Draft (nfsv4 WG) | |
|---|---|---|---|
| Authors | David Noveck , Rodney Burnett | ||
| Last updated | 2005-07-08 | ||
| Replaces | draft-noveck-nfsv4-referrals | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats |
Expired & archived
|
||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Expired | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
RFC3530 describes a migration feature using the NFS4ERR_MOVED error code and the fs_locations attribute. The description focuses on the case of migration (i.e. relocation) of a file system already known to the client. The simpler limiting case in a which a file system not previously known to the client was located elsewhere, which we here call a referral, was not clearly described. Because of this and also because of some inconsistencies and ambiguities in the text of RFC3530, there has been confusion about how the client and server should interact in performing a referral. This document provides a guide to the implementation of referrals, and in so doing, addresses the relevant problems in RFC3530.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)