Skip to main content

Using DNS SRV to Specify a Global File Namespace with NFS Version 4
RFC 6641

Revision differences

Document history

Date Rev. By Action
2015-10-14
13 (System) Notify list changed from nfsv4-chairs@ietf.org, draft-ietf-nfsv4-federated-fs-dns-srv-namespace@ietf.org to (None)
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Sean Turner
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Peter Saint-Andre
2012-06-26
13 (System) RFC published
2012-04-25
13 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2012-04-24
13 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2012-04-24
13 (System) IANA Action state changed to In Progress from Waiting on Authors
2012-04-24
13 (System) IANA Action state changed to Waiting on Authors from In Progress
2012-04-19
13 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent
2012-04-18
13 (System) IANA Action state changed to In Progress
2012-04-18
13 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent
2012-04-18
13 Amy Vezza IESG has approved the document
2012-04-18
13 Amy Vezza Closed "Approve" ballot
2012-04-18
13 Amy Vezza Ballot approval text was generated
2012-04-18
13 Martin Stiemerling State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2012-04-18
13 Martin Stiemerling Ballot writeup was changed
2012-04-18
13 Martin Stiemerling [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling
2012-03-29
13 Martin Stiemerling Responsible AD changed to Martin Stiemerling from David Harrington
2012-03-13
13 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss
2012-03-08
13 Craig Everhart New version available: draft-ietf-nfsv4-federated-fs-dns-srv-namespace-13.txt
2012-03-06
12 Ralph Droms [Ballot comment]
I've cleared my Discuss.  Thanks for addressing my Discuss and Comment points.
2012-03-06
12 Ralph Droms [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss
2012-02-29
12 Peter Saint-Andre [Ballot comment]
Thank you for fixing the service name.
2012-02-29
12 Peter Saint-Andre [Ballot Position Update] Position for Peter Saint-Andre has been changed to No Objection from Discuss
2012-02-29
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2012-02-29
12 Craig Everhart New version available: draft-ietf-nfsv4-federated-fs-dns-srv-namespace-12.txt
2012-02-28
11 David Harrington
The syntax for a service name does not permit a "." in the name. I suggest changing _domainroot._nfs to _domainroot_nfs.

Please also check the remaining …
The syntax for a service name does not permit a "." in the name. I suggest changing _domainroot._nfs to _domainroot_nfs.

Please also check the remaining discusses and comments, and submit a revised ID.
2012-02-28
11 David Harrington State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup
2012-01-09
11 Robert Sparks
[Ballot comment]
I'm moving my previous discuss point to a comment based on the most recent revision.

The original discuss text was:

>It's unusual to …
[Ballot comment]
I'm moving my previous discuss point to a comment based on the most recent revision.

The original discuss text was:

>It's unusual to standardize a directory name in a host's filesystem namespace (see section 4.1). Has the IETF done this
>before? Is it the right organization to establish this kind of convention?

The change to the text was to remove 2119 keywords from section 4.1, but the text still reads as if it is trying to establish a standard behavior, not suggest a convention (and the edit has a grammar bug). Please consider s/is be used/could be used/.

I support Peter's discuss.
2012-01-09
11 Robert Sparks [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss
2011-12-21
11 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-12-21
11 (System) New version available: draft-ietf-nfsv4-federated-fs-dns-srv-namespace-11.txt
2011-12-12
11 David Harrington State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup.
2011-12-12
11 David Harrington State changed to IESG Evaluation::AD Followup from IESG Evaluation - Defer::AD Followup.
2011-11-05
11 Ralph Droms
[Ballot comment]
1. To make sure I'm understanding the use of this SRV RR, is it
intended to provide information about the root of an …
[Ballot comment]
1. To make sure I'm understanding the use of this SRV RR, is it
intended to provide information about the root of an NFS file system
published as the "uniform file name space" for an organization?
Although the target field of the RR could point to any NFSv4 file
server, by convention as defined in this document, the target is the
root of this "uniform file name space."

2. Section 4.2 Paragraph 5:

One of the main points of SRV records is to allow the usage of
different ports on servers for provision of service I would like to
see the example here use other port than 2049 in at least one example.
Or does the NFSv4 specification say "YOU MUST ONLY USE PORT 2049"?

3. In order to facilitate the provision of both R/O and R/W copies of
the same mount point, in theory the Priority field can be used.
Lowest priority field is RO, RW are higher priority.  This document
would give advice on Priority ranges to use for different kinds of
systems.

Example:
  0.10 Read-only
  100..110  Read/Write copies
  10000..10010 Fresh Read/Write copies

Thus only clients that know what kind of copy they need will use the
appropriate subset of SRV records when selecting a server.  In this
case different sever ports would provide the different access, not
different external names.

Example:
    _nfs._tcp SRV 0 1 45503    BigServer.example.net.
    _nfs._tcp SRV 0 2 2049    SmallServer.example.net.
    _nfs._tcp SRV 101 1 49934  BigServer.example.net.
    _nfs._tcp SRV 10010 3 2049 Backend.example.net.

Due to the way how records are selected (if RFC2782 selection
algorithm is followed) the probability of using high priority servers
by read-only clients is quite low.

4. It might not be a bad idea if the draft analyzed the likely effects
of split-brain, DNS64, and so on, but I'm not sure it's necessary.

5. Assuming IANA is being asked to register these service names in the
Service Name and Transport Protocol Port Number Registry [RFC6335], it
would be helpful to identify the registry explicitly and cite RFC 6335
in section 7.

Comments 6, 7 and 8 are related to NFS rather than the SRV record
defined in this document.

6. The convention of using /domainroot-example.net and
/.domainroot-example.net for the read-only and read-write versions of
the example.net file system is not intuitive to me.  Why use the "."
prefix rather than, say, /domainroot-ro_example.net and
/domainroot-rw_example.net?

7. Similarly, why use the "." convention for mounting the filesystem
in the client?

8. Are the details of the integration process sketched in section 5
written down in more detail somewhere else?  In my opinion, I'm not
sure section 5 will ensure a uniform use of the SRV record across all
clients.
2011-11-05
11 Ralph Droms
[Ballot discuss]
Updated on 11/5/2011 for rev -10

This document proposes the use of SRV records for mapping of names
of the form <domainroot-service>.<domain> to …
[Ballot discuss]
Updated on 11/5/2011 for rev -10

This document proposes the use of SRV records for mapping of names
of the form <domainroot-service>.<domain> to a mounted filesystem in
an NFS client namespace.  My review is based on two reviews from the
DNS Directorate and my own reading of the document.

1. The service name specified for the "domainroot" function are a two
label name "_nfs._domainroot." and a three label name
"_nfs._write._domainroot."  As I understand the use of these two
service names, they identify two unique, related services for NFS
clients.  Based on the use of these service names described in this
document, there is no need for multi-label service names, and the
specification could be simplified by using, e.g., "_nfs-ro." and
"_nfs-rw." for the service names.

The discussion of ro vs. rw filesystems seems to have been mostly
elided from rev -10.  My Discuss and Comment positions are
unchanged for the new revision.

2. If there is some expectation for future service sub-types for
NFS-related service names, it would be appropriate to define a "_nfs."
service with, e.g., "_domainroot-ro." and "_domainroot-rw." subtypes.
In this case, the names for read-only and read-write domain roots
would be:

_domainroot-ro._nfs._tcp.example.com
_domainroot-rw._nfs._tcp.example.com

3. In section 4:

  "This DNS SRV record evaluation, could in principle, be done either
  in the NFSv4 client or in the NFSv4 server....."

Only the NFSv4 client can perform the DNS resolution as it
may have a different resolution context than the server in split DNS
scenarios.
2011-10-26
11 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-10-26
10 (System) New version available: draft-ietf-nfsv4-federated-fs-dns-srv-namespace-10.txt
2011-10-20
11 Cindy Morgan Removed from agenda for telechat
2011-10-20
11 Cindy Morgan State changed to IESG Evaluation - Defer::Revised ID Needed from IESG Evaluation - Defer.
2011-10-20
11 Jari Arkko [Ballot comment]
I'm not sure why the mount point conventions are needed.
2011-10-20
11 Jari Arkko
[Ballot discuss]
I do not understand why the document prohibits the use of DNS-SD to discover NFSv4 services. If I don't have a DNS server …
[Ballot discuss]
I do not understand why the document prohibits the use of DNS-SD to discover NFSv4 services. If I don't have a DNS server in my home network and I want to access information from a NFSv4 capable server, it should work, no?
2011-10-20
11 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded
2011-10-18
11 Ralph Droms
[Ballot comment]
1. To make sure I'm understanding the use of this SRV RR, is it
intended to provide information about the root of an …
[Ballot comment]
1. To make sure I'm understanding the use of this SRV RR, is it
intended to provide information about the root of an NFS file system
published as the "uniform file name space" for an organization?
Although the target field of the RR could point to any NFSv4 file
server, by convention as defined in this document, the target is the
root of this "uniform file name space."

2. Section 4.2 Paragraph 5:

One of the main points of SRV records is to allow the usage of
different ports on servers for provision of service I would like to
see the example here use other port than 2049 in at least one example.
Or does the NFSv4 specification say "YOU MUST ONLY USE PORT 2049"?

3. In order to facilitate the provision of both R/O and R/W copies of
the same mount point, in theory the Priority field can be used.
Lowest priority field is RO, RW are higher priority.  This document
would give advice on Priority ranges to use for different kinds of
systems.

Example:
  0.10 Read-only
  100..110  Read/Write copies
  10000..10010 Fresh Read/Write copies

Thus only clients that know what kind of copy they need will use the
appropriate subset of SRV records when selecting a server.  In this
case different sever ports would provide the different access, not
different external names.

Example:
    _nfs._tcp SRV 0 1 45503    BigServer.example.net.
    _nfs._tcp SRV 0 2 2049    SmallServer.example.net.
    _nfs._tcp SRV 101 1 49934  BigServer.example.net.
    _nfs._tcp SRV 10010 3 2049 Backend.example.net.

Due to the way how records are selected (if RFC2782 selection
algorithm is followed) the probability of using high priority servers
by read-only clients is quite low.

4. It might not be a bad idea if the draft analyzed the likely effects
of split-brain, DNS64, and so on, but I'm not sure it's necessary.

5. Assuming IANA is being asked to register these service names in the
Service Name and Transport Protocol Port Number Registry [RFC6335], it
would be helpful to identify the registry explicitly and cite RFC 6335
in section 7.

Comments 6, 7 and 8 are related to NFS rather than the SRV record
defined in this document.

6. The convention of using /domainroot-example.net and
/.domainroot-example.net for the read-only and read-write versions of
the example.net file system is not intuitive to me.  Why use the "."
prefix rather than, say, /domainroot-ro_example.net and
/domainroot-rw_example.net?

7. Similarly, why use the "." convention for mounting the filesystem
in the client?

8. Are the details of the integration process sketched in section 5
written down in more detail somewhere else?  In my opinion, I'm not
sure section 5 will ensure a uniform use of the SRV record across all
clients.
2011-10-18
11 Ralph Droms
[Ballot discuss]
This document proposes the use of SRV records for mapping of names
of the form <domainroot-service>.<domain> to a mounted filesystem in
an NFS …
[Ballot discuss]
This document proposes the use of SRV records for mapping of names
of the form <domainroot-service>.<domain> to a mounted filesystem in
an NFS client namespace.  My review is based on two reviews from the
DNS Directorate and my own reading of the document.

1. The service name specified for the "domainroot" function are a two
label name "_nfs._domainroot." and a three label name
"_nfs._write._domainroot."  As I understand the use of these two
service names, they identify two unique, related services for NFS
clients.  Based on the use of these service names described in this
document, there is no need for multi-label service names, and the
specification could be simplified by using, e.g., "_nfs-ro." and
"_nfs-rw." for the service names.

2. If there is some expectation for future service sub-types for
NFS-related service names, it would be appropriate to define a "_nfs."
service with, e.g., "_domainroot-ro." and "_domainroot-rw." subtypes.
In this case, the names for read-only and read-write domain roots
would be:

_domainroot-ro._nfs._tcp.example.com
_domainroot-rw._nfs._tcp.example.com

3. In section 4:

  "This DNS SRV record evaluation, could in principle, be done either
  in the NFSv4 client or in the NFSv4 server....."

Only the NFSv4 client can perform the DNS resolution as it
may have a different resolution context than the server in split DNS
scenarios.
2011-10-18
11 Ralph Droms [Ballot Position Update] New position, Discuss, has been recorded
2011-10-17
11 David Harrington Request for Early review by TSVDIR Completed. Reviewer: Joseph Touch.
2011-10-10
11 Samuel Weiler Request for Telechat review by SECDIR is assigned to Dave Cridland
2011-10-10
11 Samuel Weiler Request for Telechat review by SECDIR is assigned to Dave Cridland
2011-10-10
11 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2011-10-07
09 (System) New version available: draft-ietf-nfsv4-federated-fs-dns-srv-namespace-09.txt
2011-10-06
11 Ralph Droms
[Ballot comment]
I apologize for the late defer.  I've not had time to review this document, and I want to get a DNS Directorate review …
[Ballot comment]
I apologize for the late defer.  I've not had time to review this document, and I want to get a DNS Directorate review as well.
2011-10-06
11 Ralph Droms State changed to IESG Evaluation - Defer from Waiting for AD Go-Ahead::External Party.
2011-10-06
11 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-10-06
11 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2011-10-05
11 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded
2011-10-05
11 David Harrington
State changed to Waiting for AD Go-Ahead::External Party from Waiting for AD Go-Ahead.<br>A request has been made to have the DNS directorate review this document, …
State changed to Waiting for AD Go-Ahead::External Party from Waiting for AD Go-Ahead.<br>A request has been made to have the DNS directorate review this document, given the discussion that occurred during IETF LC.
2011-10-05
11 Pete Resnick [Ballot comment]
I agree with the concerns regarding the SRV record and the mount points.
2011-10-05
11 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded
2011-10-05
11 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2011-10-04
11 Robert Sparks [Ballot comment]
I support Peter's discuss.
2011-10-04
11 Robert Sparks
[Ballot discuss]
I expect to clear or revise this discuss quickly based on discussion:

It's unusual to standardize a directory name in a host's filesystem …
[Ballot discuss]
I expect to clear or revise this discuss quickly based on discussion:

It's unusual to standardize a directory name in a host's filesystem namespace (see section 4.1). Has the IETF done this before? Is it the right organization to establish this kind of convention?
2011-10-04
11 Robert Sparks [Ballot Position Update] New position, Discuss, has been recorded
2011-10-04
11 Adrian Farrel
[Ballot comment]
The NFS version 4 protocol provides a natural way for a collection of
  NFS file servers to collaborate in providing an organization-wide …
[Ballot comment]
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.

I love "natural." Is that just using herbal essence, or do you also use
crystals?

---

Section 3 might be a bit more definitive. No need to "propose" things in
a published RFC.
2011-10-04
11 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2011-10-04
11 Sean Turner
[Ballot comment]
s4.2: r/recommended/RECOMMENDED in the following:

  As for the other attributes in fs_locations_info, the recommended
  approach is for a client to make …
[Ballot comment]
s4.2: r/recommended/RECOMMENDED in the following:

  As for the other attributes in fs_locations_info, the recommended
  approach is for a client to make its first possible contact with any
  ...
2011-10-04
11 Sean Turner
[Ballot discuss]
This ought be easy enough to fix (it might be that I'm reading it wrong):

s5: The second paragraph includes:

  NFS clients …
[Ballot discuss]
This ought be easy enough to fix (it might be that I'm reading it wrong):

s5: The second paragraph includes:

  NFS clients compliant to this standard MUST implement this
  functionality. 

What's the "this" referring to?  The previous paragraph describes two alternatives.  Maybe just reword to say which of the two must be supported?
2011-10-04
11 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded
2011-10-04
11 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded
2011-10-03
11 Peter Saint-Andre
[Ballot discuss]
I concur with the DISCUSS raised by Russ Housley in reference to the Gen-ART review: as far as I can see, a Service …
[Ballot discuss]
I concur with the DISCUSS raised by Russ Housley in reference to the Gen-ART review: as far as I can see, a Service name of "_nfs4._domainroot" is not consistent with RFC 2782. If indeed the WG has formulated a solution to that problem ("in the form of a unitary single-level service name"), and if the WG has consensus on that proposed solution, then the I-D should be revised to incorporate that solution. Until that is done (or some other solution is found), I do not think it is appropriate to advance this specification to Proposed Standard.
2011-10-03
11 Peter Saint-Andre [Ballot Position Update] New position, Discuss, has been recorded
2011-09-30
11 Russ Housley
[Ballot discuss]
The Gen-ART Review by David Black on 26-Sept-2011 raises some
  concerns that deserve a response.  Please find the review at
  http://www.ietf.org/mail-archive/web/gen-art/current/msg06749.html …
[Ballot discuss]
The Gen-ART Review by David Black on 26-Sept-2011 raises some
  concerns that deserve a response.  Please find the review at
  http://www.ietf.org/mail-archive/web/gen-art/current/msg06749.html.
2011-09-30
11 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded
2011-09-29
11 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2011-09-23
11 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-09-16
11 Amanda Baber We understand that this document doesn't require any IANA actions.
2011-09-13
11 Amanda Baber We understand that this document doesn't require any IANA actions.
2011-09-09
11 Cindy Morgan Last call sent
2011-09-09
11 Cindy Morgan
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <nfsv4@ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call: <draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08.txt> (Using DNS SRV to Specify a Global File Name Space with NFS version 4) to Proposed Standard


The IESG has received a request from the Network File System Version 4 WG
(nfsv4) to consider the following document:
- 'Using DNS SRV to Specify a Global File Name Space with NFS version 4'
  <draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08.txt> as a Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-09-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-nfsv4-federated-fs-dns-srv-namespace/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-nfsv4-federated-fs-dns-srv-namespace/


No IPR declarations have been submitted directly on this I-D.


2011-09-09
11 David Harrington Placed on agenda for telechat - 2011-10-06
2011-09-09
11 David Harrington Last Call was requested
2011-09-09
11 David Harrington State changed to Last Call Requested from AD Evaluation::AD Followup.
2011-09-09
11 David Harrington Last Call text changed
2011-09-09
11 David Harrington [Ballot Position Update] New position, Yes, has been recorded for David Harrington
2011-09-09
11 David Harrington Ballot has been issued
2011-09-09
11 David Harrington Created "Approve" ballot
2011-09-09
11 (System) Ballot writeup text was added
2011-09-09
11 (System) Last call text was added
2011-09-02
11 David Harrington Request for Early review by TSVDIR is assigned to Joseph Touch
2011-09-02
11 David Harrington Request for Early review by TSVDIR is assigned to Joseph Touch
2011-09-02
11 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-09-02
08 (System) New version available: draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08.txt
2011-08-31
11 David Harrington
State changed to AD Evaluation::Revised ID Needed from AD Evaluation.<br>AD Review of draft-ietf-nfsv4-federated-fs-dns-srv-namespace

Looks good. A few editorial thinfgs to make things clearer.

"This functionality …
State changed to AD Evaluation::Revised ID Needed from AD Evaluation.<br>AD Review of draft-ietf-nfsv4-federated-fs-dns-srv-namespace

Looks good. A few editorial thinfgs to make things clearer.

"This functionality does not require or use any list of organizations that are known to provide file service, as AFS did with its "root.afs" functionality." I cannot tell whether AFS did or did not require using a list of organizations.

"This DNS SRV record evaluation could, in principle, be done either in the NFSv4 client or in an NFSv4 server. In either case, the result would appear the same to applications on the NFSv4 client." I think this needs better explanation, and specification of what behavior is compliant to this proposed standard. (A pointer to the later section that discusses this would work.

in 4.1, "will<"

in 5, "We strongly suggest that this functionality be implemented by NFS clients. " Can we phrase this in RFC2119 language plesae? "NFS clients compliant to this standard MUST implement this functionality" or "NFS clients  compliant to this standard SHOULD implement this functionality; the acceptable exceptions are for environments that are contrained by ...."

in 6, I am not sure what an "intrusive substitute" means. Can you expand upon this?

in 6, "It may be possible ..." I find this text confusing. Under what circumstances is it possible? Is this a deployment possibility? an implementation possibility? Do we just not know enough about DNSSEC to tell if it is or is not possible? Can you expand this?

The 2nd sentence in the 2nd paragraph says ""also breaks". This implies a previous discussion of breakage, but I don't see a previous discussion of breakage.There is an "also" in the third sentence as well

"GSS-API should be used" - is that an RFC2119 SHOULD?
2011-08-31
11 David Harrington State changed to AD Evaluation from Publication Requested.
2011-08-17
11 David Harrington Draft added in state Publication Requested
2011-08-17
11 David Harrington Changed protocol writeup
2011-02-24
07 (System) New version available: draft-ietf-nfsv4-federated-fs-dns-srv-namespace-07.txt
2011-02-22
06 (System) New version available: draft-ietf-nfsv4-federated-fs-dns-srv-namespace-06.txt
2010-08-26
05 (System) New version available: draft-ietf-nfsv4-federated-fs-dns-srv-namespace-05.txt
2010-05-25
04 (System) New version available: draft-ietf-nfsv4-federated-fs-dns-srv-namespace-04.txt
2010-03-30
03 (System) New version available: draft-ietf-nfsv4-federated-fs-dns-srv-namespace-03.txt
2009-10-26
02 (System) New version available: draft-ietf-nfsv4-federated-fs-dns-srv-namespace-02.txt
2009-05-15
01 (System) New version available: draft-ietf-nfsv4-federated-fs-dns-srv-namespace-01.txt
2009-03-30
11 (System) Document has expired
2008-09-26
00 (System) New version available: draft-ietf-nfsv4-federated-fs-dns-srv-namespace-00.txt