draft-ietf-nfsv4-federated-fs-dns-srv-namespace-01.txt   draft-ietf-nfsv4-federated-fs-dns-srv-namespace-02.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: November 16, 2009 J. Zhang Expires: April 29, 2010 J. Zhang
Google Google
May 15, 2009 October 26, 2009
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-01.txt draft-ietf-nfsv4-federated-fs-dns-srv-namespace-02.txt
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 34
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 November 16, 2009. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 17 skipping to change at page 2, line 17
clients that might not be intimately associated with such an clients that might not be intimately associated with such an
organization. The DNS SRV RR can be used to join these organization- organization. The DNS SRV RR can be used to join these organization-
wide file name spaces together to allow construction of a global, wide file name spaces together to allow construction of a global,
uniform NFS version 4 file name space. uniform NFS version 4 file name space.
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
3.1. Deployment of the Resource Record . . . . . . . . . . . . 4 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. File system integration issues . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . 7 6. Relationship to DNS NFS4ID RR . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
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
protocol [RFC3530], NFS servers can cooperate to build a file name protocol [RFC3530], NFS servers can cooperate to build a file name
space that crosses server boundaries, as detailed in the description space that crosses server boundaries, as detailed in the description
of referrals in [NB0510]. With NFS Version 4 referrals, a file of referrals in [NB0510]. With NFS Version 4 referrals, a file
server may indicate to its client that the file system name tree server may indicate to its client that the file name tree beneath a
beneath a given name in the server is not present on itself, but is given name in the server is not present on itself, but is represented
represented by a filesystem in some other set of servers. The by a filesystem in some other set of servers. The mechanism is
mechanism is general, allowing servers to describe any filesystem as general, allowing servers to describe any filesystem as being
being reachable by requests to any of a set of servers. Thus, reachable by requests to any of a set of servers. Thus, starting
starting with a single NFS Version 4 server, using these referrals, with a single NFS Version 4 server, using these referrals, an NFS
an NFS Version 4 client might be able to see a large name space Version 4 client might be able to see a large name space associated
associated with a collection of interrelated NFS Version 4 file with a collection of interrelated NFS Version 4 file servers. An
servers. An organization could use this capability to construct a organization could use this capability to construct a uniform file
uniform file name space for itself. name space for itself.
An organization might wish to publish the starting point for this An organization might wish to publish the starting point for this
name space to its clients. In many cases, the organization will want name space to its clients. In many cases, the organization will want
to publish this starting point to a broader set of possible clients. to publish this starting point to a broader set of possible clients.
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 file system 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 [RFC1035] to locate it.
As with the AFSDB resource record type [RFC1183], the client need As with the AFSDB resource record type [RFC1183], the client need
only utter the (relatively) constant domain name for an organization only utter the (relatively) constant domain name for an organization
in order to locate its file system name space service. Once a client in order to locate its filesystem name space service. Once a client
uses the DNS to locate one or more servers for the root of the uses the DNS to locate one or more servers for the root of the
organization's name space, it can use the standard NFS Version 4 organization's name space, it can use the standard NFS Version 4
mechanisms to navigate the remainder of the NFS servers for that 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 file system 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:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target _Service._Proto.Name TTL Class SRV Priority Weight Port Target
In our case, we use a Service name of "nfs4" and a conventional In our case, we use a Service name of "_nfs4._domainroot" and a
Protocol of "_tcp". The Target fields give the domain names of the conventional Protocol of "_tcp". (In accordance with RFC 2782
NFS Version 4 servers that export root filesystems. An NFS Version 4 [RFC2782], we use "_" prefix characters on the Service and Protocol
client SHOULD interpret any of the exported pseudo-root filesystems names, but we recognize that there is work in progress [Gudmundsson]
as the filesystem published by the organization with the given domain to create a registry of these names and to no longer use the "_"
name. prefix for some names.) The Target fields give the domain names of
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 filesystems as the filesystem published by the organization with
the given domain name.
Suppose a client wished to locate the root of the file system In order to allow the NFSv4 servers so given to export a variety of
published by organization example.net. The DNS servers for the filesystems, those file servers SHOULD export the given domain's root
domain could publish records like filesystems at "/.domain-root-{Name}" within their pseudo-
filesystems, where the "{Name}" is the name of the organization as
used in the SRV RR.
_nfs4._tcp IN SRV 0 0 2049 nfs1tr.example.net As an example, suppose a client wished to locate the root of the
_nfs4._tcp IN SRV 1 0 2049 nfs2ex.example.net filesystem published by organization example.net. The DNS servers
for the domain could publish records like
_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, these records are to be interpreted using the Priority and RFC 2782 [RFC2782], these records are to be interpreted using the
Weight field values, selecting an appropriate file server with which Priority and Weight field values, selecting an appropriate file
to begin a network conversation. Subsequent accesses are carried out server with which to begin a network conversation. The two file
in accordance with ordinary NFS Version 4 protocol. servers would export filesystems that would be found at "/.domain-
root-example.net" in their pseudo-filesystems, which clients would
3.1. Deployment of the Resource Record mount. Clients then carry out subsequent accesses in accordance with
the ordinary NFS Version 4 protocol.
As with any DNS resource, any server installation needs to concern
itself with the likely loads and effects of the presence of the
resource record. The answers to requests for RRs might differ
depending on what the server can tell about the client. For example,
some RRs might be returned only to those clients inside some network
perimeter (to provide an intranet service) and requests from other
clients might be denied. As the RR directs the clients to ask for
service from a given set of servers, the administrator should ensure
that the identified servers can handle the expected load.
Fortunately, the definition of the DNS SRV resource record offers a
mechanism to distribute the load to multiple servers within a
priority ordering.
4. Integration with Use of NFS Version 4 4. Integration with Use of NFS Version 4
There are at least two remaining questions: whether this DNS SRV We expect that NFSv4 clients will implement a special directory,
record evaluation is done in the NFS server or client, and also how analogous to an Automounter [AMD] directory, the entries in which are
the domain names of the organizations are passed to client or server. domain names that have recently been traversed. When an application
A third question is how this might produce a uniform global file name attempts to traverse a new name in that special directory, the NFSv4
space, and what prefix should be used for such file names. 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
special directory. The goal is that NFSv4 applications will be able
to lookup an organization's domain name in the special directory, and
the NFSv4 client will be able to discover the filesystem that that
organization publishes. Entries in the special directory will be
domain names, and they will each appear to the application as a
directory name pointing to the root directory of the filesystem
published by the organization responsible for that domain name.
This specification anticipates that these SRV records will most This functionality does not require or use any list of organizations
commonly be used to define the second directory level in an inter- that are known to provide file service, as AFS did with its
organizational file name space. This directory will be populated "root.afs" functionality.
with domain names pointing to the file systems published for use
under those domain names. Thus, the root directory for the file
system published by example.net will effectively be mounted
underneath the example.net name in a second-level directory.
In general, a domain name will appear to a client as a directory name This DNS SRV record evaluation could, in principle, be done either in
pointing to the root directory of the file system published by the the NFSv4 client or in an NFSv4 server. In either case, the result
organization responsible for that domain name. would appear the same to applications on the NFSv4 client.
4.1. Globally-useful names: conventional mount point 4.1. Globally-useful names: conventional mount point
For the inter-organizational name space to be a global name space, it For the inter-organizational name space to be a global name space, it
is useful for its mount point in local systems to be uniform as well. is useful for its mount point in local systems to be uniform as well.
The name /nfs4/ SHOULD be used so that names on one machine will be On POSIX machines, the name /nfs4/ SHOULD be used so that names on
directly usable on any machine. Thus, the example.net published file one machine will be directly usable on any machine. Thus, the
system would be accessible as example.net published filesystem would be accessible as
/nfs4/example.net/ /nfs4/example.net/
on any client. Using this convention, "/nfs4/" is a mount for a on any POSIX client. Using this convention, "/nfs4/" is the name of
special file system that is populated with the results of SRV record the special directory that is populated with domain names, leading to
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, we assume fs_locations_info. For the rootpath field of fs_location, as
that the empty string is adequate. Thus, the servers listed as mentioned, we use the "/.domain-root-{Name}" string. Thus, the
targets for the SRV resource records should export the root of the servers listed as targets for the SRV resource records should export
organization's published file system as the pseudo-root in its the root of the organization's published filesystem as the directory
exported namespace. "/.domain-root-{Name}" (for the given organization Name) in its
exported namespace. For example, for organization "example.net", the
directory "/.domain-root-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.
We recommend, though, that the process of mounting an organization's The process of mounting an organization's name space should permit
name space should permit the use of what is likely to impose the the use of what is likely to impose the lowest cost on the server.
lowest cost on the server. Thus, we recommend that the client not Thus, the NFS client SHOULD not insist on using a writable copy of
insist on using a writable copy of the filesystem if read-only copies the filesystem if read-only copies exist, or a zero-age copy rather
exist, or a zero-age copy rather than a copy that may be a little than a copy that may be a little older. We presume that the
older. We presume that the organization's file name space can be organization's file name space can be navigated to provide access to
navigated to provide access to higher-cost properties such as higher-cost properties such as writability or currency as necessary,
writability or currency as necessary, but that the default use when but that the default use when navigating to the base information for
navigating to the base information for an organization ought to be as an organization ought to be as low-overhead as possible.
low-overhead as possible.
One extension of this rule that we might choose to inherit from AFS, Because of the possible distinction between read-only and read-write
though, is to give a special meaning to the domain name of an versions of a filesystem, organizations SHOULD also publish the
organization preceded by a period ("."). It might be reasonable to location of a writable instance of their root filesystems, and that
have names mounting the filesystem for a period-prefixed domain name NFSv4 clients SHOULD mount that filesystem under the organizational
(e.g., ".example.net") attempt to mount only a read-write instance of domain name preceded by a period ("."). Therefore, when names
that organization's root filesystem, rather than permitting the use beginning with a period are looked up under the NFSv4 client's
of read-only instances of that filesystem. Thus, special directory, the SRV RR looked up in DNS uses a Service name of
"_nfs4._write._domainroot", and the indicated server (or servers)
SHOULD export the writable instance at "/.domain-root-write-{Name}"
for a domain name Name.
Extending the opening example, suppose a client wished to locate the
read-only and read-write roots of the filesystem published by
organization example.net. Suppose a read-write instance were hosted
on server nfs1tr.example.net, and read-only instances were on that
server and also on server nfs2ex.example.net. The DNS servers for
the domain would publish records like
_nfs4._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
"/.domain-root-example.net" (the read-only instance) and "/.domain-
root-write-example.net" (the read-write instance). The
nfs2ex.example.net server need export only the "/.domain-root-
example.net" name for its read-only instance.
The read-write version of the filesystem would be mounted (upon use)
under ".example.net" in the special directory, and a read-only
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
/nfs4/.example.net/users /nfs4/.example.net/users
would be a writable form of that same directory. A small benefit of would be a writable form of that same directory. A small benefit of
following this convention is that names with the period prefix are following this convention is that names with the period prefix are
treated as "hidden" in many operating systems, so that the visible treated as "hidden" in many operating systems, so that the visible
name remains the lowest-overhead name. name remains the lowest-overhead name.
4.3. File system integration issues 4.3. Filesystem integration issues
The result of the DNS search SHOULD appear as a (pseudo-)directory in The result of the DNS search SHOULD appear as a (pseudo-)directory in
the client name space, cached for a time no longer than the RR's TTL. the client name space. A further refinement is advisable, and SHOULD
A further refinement is advisable, and SHOULD be deployed: that only be deployed: that only fully-qualified domain names appear as
fully-qualified domain names appear as directories. That is, in many directories. That is, in many environments, DNS names may be
environments, DNS names may be abbreviated from their fully-qualified abbreviated from their fully-qualified form. In such circumstances,
form. In such circumstances, multiple names might be given to file multiple names might be given to filesystem code that all resolve to
system code that all resolve to the same DNS SRV RRs. The the same DNS SRV RRs. The abbreviated form SHOULD be represented in
abbreviated form SHOULD be represented in the client's name space the client's name space cache as a symbolic link, pointing to the
cache as a symbolic link, pointing to the fully-qualified name, case- fully-qualified name, case-canonicalized when appropriate. This will
canonicalized when appropriate. This will allow pathnames obtained allow pathnames obtained with, say, getcwd() to include the DNS name
with, say, getcwd() to include the DNS name that is most likely to be that is most likely to be usable outside the scope of any particular
usable outside the scope of any particular DNS abbreviation DNS abbreviation convention.
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 client or by the server, though we expect that most clients will
include this function themselves. Using something like Automounter include this function themselves. Using something like Automounter
[AMD] technology, the client would be responsible for interpreting [AMD] technology, the client would be responsible for interpreting
names under a particular directory, discovering the appropriate names under a particular directory, discovering the appropriate
filesystem to mount, and mounting it in the appropriate place in the filesystem to mount, and mounting it in the appropriate place in the
client name space before returning control to the application doing a client name space before returning control to the application doing a
lookup. Alternatively, one could imagine the existence of an NFS lookup. Alternatively, one could imagine the existence of an NFS
version 4 server that awaited similar domain-name lookups, then version 4 server that awaited similar domain-name lookups, then
consulted the DNS SRV records to determine the servers for the consulted the DNS SRV records to determine the servers for the
indicated published file system, and then returned that information indicated published filesystem, and then returned that information
via NFS Version 4 attributes as a referral in the way outlined by via NFS Version 4 attributes as a referral in the way outlined by
Noveck and Burnett [NB0510]. In either case, the result of the DNS Noveck and Burnett [NB0510]. In either case, the result of the DNS
lookup should be cached (obeying TTL) so that the result could be lookup should be cached (obeying TTL) so that the 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
skipping to change at page 8, line 26 skipping to change at page 9, line 6
Thus, it would likely be prudent also to use domain-based service Thus, it would likely be prudent also to use domain-based service
principal names for the servers for the root filesystems as indicated principal names for the servers for the root filesystems as indicated
as the targets of the SRV records. The idea here is that one wants as the targets of the SRV records. The idea here is that one wants
to authenticate {nfs, domainname, host.fqdn}, not simply {nfs, to authenticate {nfs, domainname, host.fqdn}, not simply {nfs,
host.fqdn}, when the server is a domain's root file server obtained host.fqdn}, when the server is a domain's root file server obtained
through an insecure DNS SRV RR lookup. The domain administrator can through an insecure DNS SRV RR lookup. The domain administrator can
thus ensure that only domain root NFSv4 servers have credentials for thus ensure that only domain root NFSv4 servers have credentials for
such domain-based service principal names. such domain-based service principal names.
Domain-based service principal names are defined in RFCs 5178 Domain-based service principal names are defined in RFCs 5178
[RFC3530] and 5179 [RFC3530]. To make use of RFC 5178's domain-based [RFC5178] and 5179 [RFC5179]. To make use of RFC 5178's domain-based
names, the syntax for "domain-based-name" MUST be used with a service names, the syntax for "domain-based-name" MUST be used with a service
of "nfs", a domain matching the name of the organization whose root of "nfs", a domain matching the name of the organization whose root
filesystem is being sought, and a hostname given in the target of the filesystem is being sought, and a hostname given in the target of the
DNS SRV resource record. Thus, in the example above, two file DNS SRV resource record. Thus, in the example above, two file
servers (nfs1tr.example.net and nfs2ex.example.net) are located as servers (nfs1tr.example.net and nfs2ex.example.net) are located as
hosting the root filesystem for the organization example.net. To hosting the root filesystem for the organization example.net. To
communicate with, for instance, the second of the given file servers, communicate with, for instance, the second of the given file servers,
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
skipping to change at page 9, line 46 skipping to change at page 10, line 26
[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.,
and E. Zayas, "DEcorum File System Architectural and E. Zayas, "DEcorum File System Architectural
Overview", Proc. USENIX Summer Conf. Anaheim, Calif., Overview", Proc. USENIX Summer Conf. Anaheim, Calif.,
June 1990. June 1990.
[Gudmundsson]
Gudmundsson, O. and A. Hoenes, "Creation of a Registry for
DNS SRV Record Service Prefixes", October 2009, <ftp://
ftp.rfc-editor.org/in-notes/internet-drafts/
draft-gudmundsson-dns-srv-iana-registry-04.txt>.
[NB0510] Noveck, D. and R. Burnett, "Next Steps for NFSv4 [NB0510] Noveck, D. and R. Burnett, "Next Steps for NFSv4
Migration/Replication", October 2005, <ftp://www.ietf.org/ Migration/Replication", October 2005, <ftp://www.ietf.org/
internet-drafts/draft-noveck-nfsv4-migrep-00.txt>. internet-drafts/draft-noveck-nfsv4-migrep-00.txt>.
[RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P. [RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P.
Mockapetris, "New DNS RR Definitions", RFC 1183, Mockapetris, "New DNS RR Definitions", RFC 1183,
October 1990. October 1990.
Authors' Addresses Authors' Addresses
 End of changes. 29 change blocks. 
111 lines changed or deleted 143 lines changed or added

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