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 |