draft-ietf-nfsv4-federated-fs-dns-srv-namespace-02.txt   draft-ietf-nfsv4-federated-fs-dns-srv-namespace-03.txt 
Network Working Group C. Everhart Network Working Group C. Everhart
Internet-Draft W. Adamson Internet-Draft W. Adamson
Intended status: Standards Track NetApp Intended status: Standards Track NetApp
Expires: April 29, 2010 J. Zhang Expires: October 1, 2010 J. Zhang
Google Google
October 26, 2009 March 30, 2010
Using DNS SRV to Specify a Global File Name Space with NFS version 4 Using DNS SRV to Specify a Global File Name Space with NFS version 4
draft-ietf-nfsv4-federated-fs-dns-srv-namespace-02.txt draft-ietf-nfsv4-federated-fs-dns-srv-namespace-03.txt
Abstract
The NFS version 4 protocol provides a natural way for a collection of
NFS file servers to collaborate in providing an organization-wide
file name space. The DNS SRV RR allows a simple and appropriate way
for an organization to publish the root of its name space, even to
clients that might not be intimately associated with such an
organization. The DNS SRV RR can be used to join these organization-
wide file name spaces together to allow construction of a global,
uniform NFS version 4 file name space.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 45
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010. This Internet-Draft will expire on October 1, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
The NFS version 4 protocol provides a natural way for a collection of This document may contain material from IETF Documents or IETF
NFS file servers to collaborate in providing an organization-wide Contributions published or made publicly available before November
file name space. The DNS SRV RR allows a simple and appropriate way 10, 2008. The person(s) controlling the copyright in some of this
for an organization to publish the root of its name space, even to material may not have granted the IETF Trust the right to allow
clients that might not be intimately associated with such an modifications of such material outside the IETF Standards Process.
organization. The DNS SRV RR can be used to join these organization- Without obtaining an adequate license from the person(s) controlling
wide file name spaces together to allow construction of a global, the copyright in such materials, this document may not be modified
uniform NFS version 4 file name space. outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Proposed Use of SRV Resource Record in DNS . . . . . . . . . . 3 3. Proposed Use of SRV Resource Record in DNS . . . . . . . . . . 3
4. Integration with Use of NFS Version 4 . . . . . . . . . . . . 4 4. Integration with Use of NFS Version 4 . . . . . . . . . . . . 5
4.1. Globally-useful names: conventional mount point . . . . . 5 4.1. Globally-useful names: conventional mount point . . . . . 5
4.2. Mount options . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Mount options . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Filesystem integration issues . . . . . . . . . . . . . . 7 4.3. Filesystem integration issues . . . . . . . . . . . . . . 7
5. Where is this integration carried out? . . . . . . . . . . . . 7 5. Where is this integration carried out? . . . . . . . . . . . . 7
6. Relationship to DNS NFS4ID RR . . . . . . . . . . . . . . . . 8 6. Relationship to DNS NFS4ID RR . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Background 2. Background
With the advent of fs_locations attributes in the NFS Version 4 With the advent of fs_locations attributes in the NFS Version 4
skipping to change at page 3, line 41 skipping to change at page 4, line 41
At the same time, it is useful to require clients to know only the At the same time, it is useful to require clients to know only the
smallest amount of information in order to locate the appropriate smallest amount of information in order to locate the appropriate
name space. Simultaneously, that required information should be name space. Simultaneously, that required information should be
constant through the life of an organization if the clients are not constant through the life of an organization if the clients are not
to require reconfiguration as administrative events change, for to require reconfiguration as administrative events change, for
instance, a server's name or address. instance, a server's name or address.
3. Proposed Use of SRV Resource Record in DNS 3. Proposed Use of SRV Resource Record in DNS
Providing an organization's published filesystem name space is a Providing an organization's published filesystem name space is a
service, and it is appropriate to use the DNS [RFC1035] to locate it. service, and it is appropriate to use the DNS [RFC1034][RFC1035] to
As with the AFSDB resource record type [RFC1183], the client need locate it. As with the AFSDB resource record type [RFC1183], the
only utter the (relatively) constant domain name for an organization client need only utter the (relatively) constant domain name for an
in order to locate its filesystem name space service. Once a client organization in order to locate its filesystem name space service.
uses the DNS to locate one or more servers for the root of the Once a client uses the DNS to locate one or more servers for the root
organization's name space, it can use the standard NFS Version 4 of the organization's name space, it can use the standard NFS Version
mechanisms to navigate the remainder of the NFS servers for that 4 mechanisms to navigate the remainder of the NFS servers for that
organization. The use of this proposed mechanism results in a useful organization. The use of this proposed mechanism results in a useful
cross-organizational name space, just as in AFS [AFS] and DCE/DFS cross-organizational name space, just as in AFS [AFS] and DCE/DFS
[DFS] before it. A client need know only the name of the [DFS] before it. A client need know only the name of the
organization in order to locate the filesystem name space published organization in order to locate the filesystem name space published
by that organization. by that organization.
We propose the use of the DNS SRV resource record type [RFC2782] to We propose the use of the DNS SRV resource record type [RFC2782] to
fulfill this function. The format of the DNS SRV record is as fulfill this function. The format of the DNS SRV record is as
follows: follows:
skipping to change at page 4, line 26 skipping to change at page 5, line 26
names, but we recognize that there is work in progress [Gudmundsson] names, but we recognize that there is work in progress [Gudmundsson]
to create a registry of these names and to no longer use the "_" to create a registry of these names and to no longer use the "_"
prefix for some names.) The Target fields give the domain names of prefix for some names.) The Target fields give the domain names of
the NFS Version 4 servers that export filesystems for the domain's the NFS Version 4 servers that export filesystems for the domain's
root. An NFS Version 4 client SHOULD interpret any of the exported root. An NFS Version 4 client SHOULD interpret any of the exported
root filesystems as the filesystem published by the organization with root filesystems as the filesystem published by the organization with
the given domain name. the given domain name.
In order to allow the NFSv4 servers so given to export a variety of In order to allow the NFSv4 servers so given to export a variety of
filesystems, those file servers SHOULD export the given domain's root filesystems, those file servers SHOULD export the given domain's root
filesystems at "/.domain-root-{Name}" within their pseudo- filesystems at "/.domainroot-{Name}" within their pseudo-filesystems,
filesystems, where the "{Name}" is the name of the organization as where the "{Name}" is the name of the organization as used in the SRV
used in the SRV RR. RR.
As an example, suppose a client wished to locate the root of the As an example, suppose a client wished to locate the root of the
filesystem published by organization example.net. The DNS servers filesystem published by organization example.net. The DNS servers
for the domain could publish records like for the domain could publish records like
_nfs4._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net $ORIGIN example.net.
_nfs4._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net _nfs4._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net.
_nfs4._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net.
The result domain names nfs1tr.example.net and nfs2ex.example.net The result domain names nfs1tr.example.net and nfs2ex.example.net
indicate NFS Version 4 file servers that export the root of the indicate NFS Version 4 file servers that export the root of the
published name space for the example.net domain. In accordance with published name space for the example.net domain. In accordance with
RFC 2782 [RFC2782], these records are to be interpreted using the RFC 2782 [RFC2782], these records are to be interpreted using the
Priority and Weight field values, selecting an appropriate file Priority and Weight field values, selecting an appropriate file
server with which to begin a network conversation. The two file server with which to begin a network conversation. The two file
servers would export filesystems that would be found at "/.domain- servers would export filesystems that would be found at
root-example.net" in their pseudo-filesystems, which clients would "/.domainroot-example.net" in their pseudo-filesystems, which clients
mount. Clients then carry out subsequent accesses in accordance with would mount. Clients then carry out subsequent accesses in
the ordinary NFS Version 4 protocol. accordance with the ordinary NFS Version 4 protocol.
We use a composite Service name (built from "_nfs4" and
"_domainroot") so that other filesystem protocols could make use of
the same "_domainroot" abstraction.
4. Integration with Use of NFS Version 4 4. Integration with Use of NFS Version 4
We expect that NFSv4 clients will implement a special directory, We expect that NFSv4 clients will implement a special directory,
analogous to an Automounter [AMD] directory, the entries in which are analogous to an Automounter [AMD] directory, the entries in which are
domain names that have recently been traversed. When an application domain names that have recently been traversed. When an application
attempts to traverse a new name in that special directory, the NFSv4 attempts to traverse a new name in that special directory, the NFSv4
client consults DNS to obtain the SRV data for the given name, and if client consults DNS to obtain the SRV data for the given name, and if
successful, it mounts the indicated filesystem(s) in that name in the successful, it mounts the indicated filesystem(s) in that name in the
special directory. The goal is that NFSv4 applications will be able special directory. The goal is that NFSv4 applications will be able
skipping to change at page 5, line 45 skipping to change at page 6, line 49
on any POSIX client. Using this convention, "/nfs4/" is the name of on any POSIX client. Using this convention, "/nfs4/" is the name of
the special directory that is populated with domain names, leading to the special directory that is populated with domain names, leading to
file servers and filesystems that capture the results of SRV record file servers and filesystems that capture the results of SRV record
lookups. lookups.
4.2. Mount options 4.2. Mount options
SRV records are necessarily less complete than the information in the SRV records are necessarily less complete than the information in the
existing NFS Version 4 attributes fs_locations and the proposed existing NFS Version 4 attributes fs_locations and the proposed
fs_locations_info. For the rootpath field of fs_location, as fs_locations_info. For the rootpath field of fs_location, as
mentioned, we use the "/.domain-root-{Name}" string. Thus, the mentioned, we use the "/.domainroot-{Name}" string. Thus, the
servers listed as targets for the SRV resource records should export servers listed as targets for the SRV resource records should export
the root of the organization's published filesystem as the directory the root of the organization's published filesystem as the directory
"/.domain-root-{Name}" (for the given organization Name) in its "/.domainroot-{Name}" (for the given organization Name) in its
exported namespace. For example, for organization "example.net", the exported namespace. For example, for organization "example.net", the
directory "/.domain-root-example.net" should be used. directory "/.domainroot-example.net" should be used.
As for the other attributes in fs_locations_info, the recommended As for the other attributes in fs_locations_info, the recommended
approach is for a client to make its first possible contact with any approach is for a client to make its first possible contact with any
of the referred-to servers, obtain the fs_locations_info structure of the referred-to servers, obtain the fs_locations_info structure
from that server, and use the information from that obtained from that server, and use the information from that obtained
structure as the basis for its judgment of whether it would be better structure as the basis for its judgment of whether it would be better
to use a different server representative from the set of servers for to use a different server representative from the set of servers for
that filesystem. that filesystem.
The process of mounting an organization's name space should permit The process of mounting an organization's name space should permit
the use of what is likely to impose the lowest cost on the server. the use of what is likely to impose the lowest cost on the server.
Thus, the NFS client SHOULD not insist on using a writable copy of Thus, the NFS client SHOULD NOT insist on using a writable copy of
the filesystem if read-only copies exist, or a zero-age copy rather the filesystem if read-only copies exist, or a zero-age copy rather
than a copy that may be a little older. We presume that the than a copy that may be a little older. We presume that the
organization's file name space can be navigated to provide access to organization's file name space can be navigated to provide access to
higher-cost properties such as writability or currency as necessary, higher-cost properties such as writability or currency as necessary,
but that the default use when navigating to the base information for but that the default use when navigating to the base information for
an organization ought to be as low-overhead as possible. an organization ought to be as low-overhead as possible.
Because of the possible distinction between read-only and read-write Because of the possible distinction between read-only and read-write
versions of a filesystem, organizations SHOULD also publish the versions of a filesystem, organizations SHOULD also publish the
location of a writable instance of their root filesystems, and that location of a writable instance of their root filesystems, and that
NFSv4 clients SHOULD mount that filesystem under the organizational NFSv4 clients SHOULD mount that filesystem under the organizational
domain name preceded by a period ("."). Therefore, when names domain name preceded by a period ("."). Therefore, when names
beginning with a period are looked up under the NFSv4 client's beginning with a period are looked up under the NFSv4 client's
special directory, the SRV RR looked up in DNS uses a Service name of special directory, the SRV RR looked up in DNS uses a Service name of
"_nfs4._write._domainroot", and the indicated server (or servers) "_nfs4._write._domainroot", and the indicated server (or servers)
SHOULD export the writable instance at "/.domain-root-write-{Name}" SHOULD export the writable instance at "/.domainroot-write-{Name}"
for a domain name Name. for a domain name Name.
Extending the opening example, suppose a client wished to locate the Extending the opening example, suppose a client wished to locate the
read-only and read-write roots of the filesystem published by read-only and read-write roots of the filesystem published by
organization example.net. Suppose a read-write instance were hosted organization example.net. Suppose a read-write instance were hosted
on server nfs1tr.example.net, and read-only instances were on that on server nfs1tr.example.net, and read-only instances were on that
server and also on server nfs2ex.example.net. The DNS servers for server and also on server nfs2ex.example.net. The DNS servers for
the domain would publish records like the domain would publish records like
_nfs4._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net $ORIGIN example.net.
_nfs4._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net _nfs4._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net.
_nfs4._write._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net _nfs4._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net.
_nfs4._write._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net.
The nfs1tr.example.net server would export filesystems at both The nfs1tr.example.net server would export filesystems at both
"/.domain-root-example.net" (the read-only instance) and "/.domain- "/.domainroot-example.net" (the read-only instance) and
root-write-example.net" (the read-write instance). The "/.domainroot-write-example.net" (the read-write instance). The
nfs2ex.example.net server need export only the "/.domain-root- nfs2ex.example.net server need export only the "/.domainroot-
example.net" name for its read-only instance. example.net" name for its read-only instance.
The read-write version of the filesystem would be mounted (upon use) The read-write version of the filesystem would be mounted (upon use)
under ".example.net" in the special directory, and a read-only under ".example.net" in the special directory, and a read-only
version would be mounted under "example.net". Thus, version would be mounted under "example.net". Thus,
/nfs4/example.net/users /nfs4/example.net/users
might be a directory in a read-only instance of the root filesystem might be a directory in a read-only instance of the root filesystem
of the organization "example.net", while of the organization "example.net", while
skipping to change at page 7, line 40 skipping to change at page 8, line 41
the client's name space cache as a symbolic link, pointing to the the client's name space cache as a symbolic link, pointing to the
fully-qualified name, case-canonicalized when appropriate. This will fully-qualified name, case-canonicalized when appropriate. This will
allow pathnames obtained with, say, getcwd() to include the DNS name allow pathnames obtained with, say, getcwd() to include the DNS name
that is most likely to be usable outside the scope of any particular that is most likely to be usable outside the scope of any particular
DNS abbreviation convention. DNS abbreviation convention.
5. Where is this integration carried out? 5. Where is this integration carried out?
Another consideration is what agent should be responsible for Another consideration is what agent should be responsible for
interpreting the SRV records. It could be done just as well by the interpreting the SRV records. It could be done just as well by the
client or by the server, though we expect that most clients will NFS client or by the NFS server, though we expect that most clients
include this function themselves. Using something like Automounter will include this function themselves. Using something like
[AMD] technology, the client would be responsible for interpreting Automounter [AMD] technology, the client would be responsible for
names under a particular directory, discovering the appropriate interpreting names under a particular directory, discovering the
filesystem to mount, and mounting it in the appropriate place in the appropriate filesystem to mount, and mounting it in the appropriate
client name space before returning control to the application doing a place in the client name space before returning control to the
lookup. Alternatively, one could imagine the existence of an NFS application doing a lookup. Alternatively, one could imagine the
version 4 server that awaited similar domain-name lookups, then existence of an NFS version 4 server that awaited similar domain-name
consulted the DNS SRV records to determine the servers for the lookups, then consulted the SRV records in DNS to determine the
indicated published filesystem, and then returned that information servers for the indicated published filesystem, and then returned
via NFS Version 4 attributes as a referral in the way outlined by that information as an NFS Version 4 referral. In either case, the
Noveck and Burnett [NB0510]. In either case, the result of the DNS result of the DNS lookup should be cached (obeying TTL) so that the
lookup should be cached (obeying TTL) so that the result could be result could be returned more quickly the next time.
returned more quickly the next time.
We strongly suggest that this functionality be implemented by NFS We strongly suggest that this functionality be implemented by NFS
clients. While we recognize that it would be possible to configure clients. While we recognize that it would be possible to configure
clients so that they relied on a specially-configured server to do clients so that they relied on a specially-configured server to do
their SRV lookups for them, we feel that such a requirement would their SRV lookups for them, we feel that such a requirement would
impose unusual dependencies and vulnerabilities for the deployers of impose unusual dependencies and vulnerabilities for the deployers of
such clients. such clients. Yet even if it is desirable to deploy this
functionality on the NFS client side, it may be valuable as a
transition aid for a site to be able to deploy it on the NFS server
side: it may be easier for them to install it on special NFS servers
rather than install it on all their NFS clients. Thus, from an
implementation standpoint, NFS clients SHOULD implement the
functionality, and NFS servers MAY implement it.
6. Relationship to DNS NFS4ID RR 6. Relationship to DNS NFS4ID RR
This DNS use has no obvious relationship to the NFS4ID RR. The This DNS use has no obvious relationship to the NFS4ID RR. The
NFS4ID RR is a mechanism to help clients and servers configure NFS4ID RR is a mechanism to help clients and servers configure
themselves with respect to the domain strings used in "who" strings themselves with respect to the domain strings used in "who" strings
in ACL entries and in owner and group names. The authentication/ in ACL entries and in owner and group names. The authentication/
authorization domain string of a server need have no direct authorization domain string of a server need have no direct
relationship to the name of the organization that is publishing a relationship to the name of the organization that is publishing a
file name space of which this server's filesystems form a part. At file name space of which this server's filesystems form a part. At
skipping to change at page 9, line 24 skipping to change at page 10, line 28
GSS-API should be used with the name-type of GSS-API should be used with the name-type of
GSS_C_NT_DOMAINBASED_SERVICE defined in RFC 5178 and with a symbolic GSS_C_NT_DOMAINBASED_SERVICE defined in RFC 5178 and with a symbolic
name of name of
nfs@example.net@nfs2ex.example.net nfs@example.net@nfs2ex.example.net
in order to verify that the named server (nfs2ex.example.net) is in order to verify that the named server (nfs2ex.example.net) is
authorized to provide the root filesystem for the example.net authorized to provide the root filesystem for the example.net
organization. organization.
8. References 8. IANA Considerations
8.1. Normative References This document does not raise actions for IANA, but it may require
cosmetic changes if the in-progress work in the Gudmundsson/Hoenes
draft [Gudmundsson] is adopted.
9. References
9.1. Normative References
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
RFC 1034, November 1987. RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and [RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, November 1987. Specification", RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", March 1997.
skipping to change at page 10, line 11 skipping to change at page 11, line 23
[RFC5178] Williams, N. and A. Melnikov, "Generic Security Service [RFC5178] Williams, N. and A. Melnikov, "Generic Security Service
Application Program Interface (GSS-API) Application Program Interface (GSS-API)
Internationalization and Domain-Based Service Names and Internationalization and Domain-Based Service Names and
Name Type", RFC 5178, May 2008. Name Type", RFC 5178, May 2008.
[RFC5179] Williams, N., "Generic Security Service Application [RFC5179] Williams, N., "Generic Security Service Application
Program Interface (GSS-API) Domain-Based Service Names Program Interface (GSS-API) Domain-Based Service Names
Mapping for the Kerberos V GSS Mechanism", RFC 5179, Mapping for the Kerberos V GSS Mechanism", RFC 5179,
May 2008. May 2008.
8.2. Informative References 9.2. Informative References
[AFS] Howard, J., "An Overview of the Andrew File System"", [AFS] Howard, J., "An Overview of the Andrew File System"",
Proc. USENIX Winter Tech. Conf. Dallas, February 1988. Proc. USENIX Winter Tech. Conf. Dallas, February 1988.
[AMD] Pendry, J. and N. Williams, "Amd: The 4.4 BSD Automounter [AMD] Pendry, J. and N. Williams, "Amd: The 4.4 BSD Automounter
Reference Manual", March 1991, Reference Manual", March 1991,
<http://docs.freebsd.org/info/amdref/amdref.pdf>. <http://docs.freebsd.org/info/amdref/amdref.pdf>.
[DFS] Kazar, M., Leverett, B., Anderson, O., Apostolides, V., [DFS] Kazar, M., Leverett, B., Anderson, O., Apostolides, V.,
Bottos, B., Chutani, S., Everhart, C., Mason, W., Tu, S., Bottos, B., Chutani, S., Everhart, C., Mason, W., Tu, S.,
 End of changes. 25 change blocks. 
69 lines changed or deleted 103 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/