Implementation Guide for Referrals in NFSv4
draft-ietf-nfsv4-referrals-00
| Document | Type | Expired Internet-Draft (nfsv4 WG) | |
|---|---|---|---|
| Last updated | 2005-07-08 | ||
| Replaces | draft-noveck-nfsv4-referrals | ||
| Stream | IETF | ||
| Intended RFC status | (None) | ||
| Formats |
Expired & archived
plain text
pdf
html
bibtex
|
||
| Stream | WG state | WG Document | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | Expired | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
https://www.ietf.org/archive/id/draft-ietf-nfsv4-referrals-00.txt
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
David Noveck
(dnoveck@netapp.com)
Rodney Burnett
(cburnett@us.ibm.com)
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)