Skip to main content

RPC: Remote Procedure Call Protocol Specification Version 2
RFC 5531

Revision differences

Document history

Date Rev. By Action
2020-01-21
13 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-10-14
13 (System) Notify list changed from nfsv4-chairs@ietf.org, draft-ietf-nfsv4-rfc1831bis@ietf.org to (None)
2012-08-22
13 (System) post-migration administrative database adjustment to the No Record position for Cullen Jennings
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Chris Newman
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Pasi Eronen
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
13 (System) post-migration administrative database adjustment to the Yes position for Lars Eggert
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2009-05-05
13 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2009-05-05
13 Amy Vezza [Note]: 'RFC 5531' added by Amy Vezza
2009-05-04
13 (System) RFC published
2009-04-16
13 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2009-04-16
13 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2009-04-16
13 (System) IANA Action state changed to In Progress from Waiting on Authors
2009-04-15
13 (System) IANA Action state changed to Waiting on Authors from In Progress
2009-03-05
13 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2009-03-05
13 (System) IANA Action state changed to In Progress
2009-03-05
13 Amy Vezza IESG state changed to Approved-announcement sent
2009-03-05
13 Amy Vezza IESG has approved the document
2009-03-05
13 Amy Vezza Closed "Approve" ballot
2009-03-05
13 Lars Eggert State Changes to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed by Lars Eggert
2009-03-05
13 (System) New version available: draft-ietf-nfsv4-rfc1831bis-13.txt
2009-02-27
13 (System) Removed from agenda for telechat - 2009-02-26
2009-02-26
13 Amy Vezza State Changes to Approved-announcement to be sent::Point Raised - writeup needed from Approved-announcement to be sent by Amy Vezza
2009-02-26
13 David Ward [Ballot Position Update] New position, No Objection, has been recorded by David Ward
2009-02-26
13 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2009-02-24
13 Lars Eggert Needs one more ballot position.
2009-02-24
13 Lars Eggert Placed on agenda for telechat - 2009-02-26 by Lars Eggert
2009-02-19
13 Lars Eggert State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Lars Eggert
2009-02-19
13 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2009-02-19
13 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2009-02-19
13 Chris Newman [Ballot Position Update] Position for Chris Newman has been changed to No Objection from Discuss by Chris Newman
2009-02-08
13 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to Yes from Discuss by Lars Eggert
2009-02-06
12 (System) New version available: draft-ietf-nfsv4-rfc1831bis-12.txt
2009-02-02
13 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Undefined from Discuss by Cullen Jennings
2009-02-02
13 Pasi Eronen [Ballot comment]
Editorial nit: Section 8.3, the chart isn't actually "in groups of
hexadecimal 20000000" any more (it was in 1831).
2009-02-02
13 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen
2009-01-30
13 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2009-01-30
13 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-01-30
11 (System) New version available: draft-ietf-nfsv4-rfc1831bis-11.txt
2008-12-13
13 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Shawn Emery.
2008-12-11
13 Cullen Jennings
[Ballot discuss]
The security portions of this protocol are not implementable from this specification or anything it normatively references. I would be looking for the …
[Ballot discuss]
The security portions of this protocol are not implementable from this specification or anything it normatively references. I would be looking for the draft to normative reference, or include in it, enough specification that I could implement all the options in an interoperable way. Then I would want all the normal rules for moving to Draft Standard to be considered for the added material. I have no problem with one of the Security ADs taking over this discuss if that would help reduce the of people involved with resolving the discuss.
2008-12-11
13 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2008-12-11
13 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2008-12-11
13 Jari Arkko
[Ballot comment]
Christian Vogt's review:

Document..........:  draft-ietf-nfsv4-rfc1831bis-10
Reviewer..........:  Christian Vogt
Review date.......:  December 11, 2008
IESG Telechat date:  December 11, 2008


Summary: This draft is …
[Ballot comment]
Christian Vogt's review:

Document..........:  draft-ietf-nfsv4-rfc1831bis-10
Reviewer..........:  Christian Vogt
Review date.......:  December 11, 2008
IESG Telechat date:  December 11, 2008


Summary: This draft is basically ready for publication, but has nits
        that should be fixed before publication.


Document draft-ietf-nfsv4-rfc1831bis-10 is an update of the "Remote
Procedure Call Protocol Specification Version 2", RFC 1831.  It seeks to
promote the RPC protocol to draft standard.  The document is overall in
good quality.

However, one aspect where I found the document to be insufficient is in
the specification of security methods.  The documents does list possible
security methods, but it neither specifies them, nor does it state a
mandatory-to-support method other than null-authentication.  I am aware
that the predecessor document, RFC 1831 also did not attend to security
methods any more carefully.  But the security-related requirements for
IETF documents have become stricter since the publication of the
predecessor document in 1995, which implies that this document would
need to pay more attention to security-related aspects.

Suggestion:  Could the list of possible security methods (alias
"security flavors") be limited to those for which there are clear
protocol specifications?  E.g., one of the possible methods, AUTH_DH,
currently refers to an academic publication rather than a protocol
specification.  That's insufficient.  And could one of the non-null
security methods be made mandatory?
2008-12-11
13 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2008-12-11
13 Pasi Eronen
[Ballot comment]
Editorial nits:
- Section 8.3, the chart isn't actually "in groups of hexadecimal
  20000000" any more (it was in 1831).
- Section …
[Ballot comment]
Editorial nits:
- Section 8.3, the chart isn't actually "in groups of hexadecimal
  20000000" any more (it was in 1831).
- Section 8.4.2: there's an extra blank link in middle of the 1st
  paragraph.
- The names of RPCSEC_GSS related errors don't match RFC 2203.
- Section 16 has old email address for IANA.

From Shawn Emery's SecDir review:
- s/in future/in the future/ (twice)
- s/to used on/to be used on/
2008-12-11
13 Pasi Eronen
[Ballot discuss]
The document should give the initial contents for the authentication
flavor registry (and this should include AUTH_KERB and all other
old/obsolete mechanisms, too). …
[Ballot discuss]
The document should give the initial contents for the authentication
flavor registry (and this should include AUTH_KERB and all other
old/obsolete mechanisms, too). This table should probably mention that
flavors 0..3 have been also called with different names earlier
(AUTH_NULL/UNIX/SHORT/DES), and give pointers to the RFCs that
define these mechanisms.

Should the document say how new values for "auth_stat" enum are
allocated?
2008-12-11
13 Pasi Eronen [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen
2008-12-10
13 Lisa Dusseault [Ballot comment]
I support the various DISCUSS positions
2008-12-10
13 Lisa Dusseault [Ballot Position Update] New position, Abstain, has been recorded by Lisa Dusseault
2008-12-10
13 Chris Newman
[Ballot discuss]
This does not seem to comply with BCP 61 (RFC 3365), which requires a
mandatory to implement authentication mechanism.  The RPCSEC_GSS …
[Ballot discuss]
This does not seem to comply with BCP 61 (RFC 3365), which requires a
mandatory to implement authentication mechanism.  The RPCSEC_GSS
mechanism would suffice as a MITM if it were a normative reference.
2008-12-10
13 Chris Newman [Ballot Position Update] New position, Discuss, has been recorded by Chris Newman
2008-12-10
13 Tim Polk
[Ballot discuss]
I support Russ's and Cullen's DISCUSSes.

As noted in the warning on the front of RFC 2695,
AUTH_DH is also vulnerable to …
[Ballot discuss]
I support Russ's and Cullen's DISCUSSes.

As noted in the warning on the front of RFC 2695,
AUTH_DH is also vulnerable to the small subgroup
attack.  AUTH_DH should probably get the same caveats
as AUTH_SYS in the security considerations section.

This document also needs to have positive rather than
negative requirements for authentication mechanisms.
Something like:

  Standards-track RPC services MUST mandate support for
  RPCSEC_GSS, and MUST mandate support for an
  authentication pseudo-flavor with appropriate levels
  of security, such as .

RPCSEC_GSS and the listed pseudo flavors need to move
from informative to normative, as well.
2008-12-10
13 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2008-12-10
13 Cullen Jennings [Ballot discuss]
The security portions of this protocol are not implementable from this specification or anythign it normatively references.
2008-12-10
13 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Discuss from No Objection by Cullen Jennings
2008-12-10
13 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2008-12-10
13 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2008-12-10
13 Russ Housley
[Ballot discuss]
The implementation report, which can be found at
  http://www.ietf.org/IESG/Implementations/report-rfc1831.txt, raises
  a question about AUTH_DH.  It appears that only one implementation …
[Ballot discuss]
The implementation report, which can be found at
  http://www.ietf.org/IESG/Implementations/report-rfc1831.txt, raises
  a question about AUTH_DH.  It appears that only one implementation
  supports AUTH_DH.  The amount of documentation is pretty sparce,
  which may be one reason that it is not supported more widely.
  Should AUTH_DH be removed from the Draft Standard specification?
2008-12-10
13 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2008-12-10
13 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2008-11-18
13 Lars Eggert Telechat date was changed to 2008-12-11 from 2008-12-04 by Lars Eggert
2008-11-17
13 Lars Eggert Telechat date was changed to 2008-12-04 from 2008-12-18 by Lars Eggert
2008-11-17
13 Lars Eggert [Ballot discuss]
IANA has questions
2008-11-17
13 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to Discuss from Yes by Lars Eggert
2008-11-17
13 Lars Eggert [Ballot Position Update] New position, Yes, has been recorded for Lars Eggert
2008-11-17
13 Lars Eggert Ballot has been issued by Lars Eggert
2008-11-17
13 Lars Eggert Created "Approve" ballot
2008-11-17
13 Lars Eggert State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Lars Eggert
2008-11-13
13 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-11-11
13 Samuel Weiler Request for Last Call review by SECDIR is assigned to Shawn Emery
2008-11-11
13 Samuel Weiler Request for Last Call review by SECDIR is assigned to Shawn Emery
2008-11-10
13 Amanda Baber
IANA Last Call comments:

IANA has questions:

- The document suggests that IANA start allocations at 0x00061a80, but
also states that previous assignments start at …
IANA Last Call comments:

IANA has questions:

- The document suggests that IANA start allocations at 0x00061a80, but
also states that previous assignments start at 0x000186a0. What about
0x00000001 - 0x0001869f? We've assumed those are reserved.

- The document suggests that a list of existing Authentication Flavors
and Pseudo-Flavors exists, but no such list is provided by value or
by reference in this document. Could you provide this list?

- In a similar vein, could you provide the allocation policy table
for the authentication flavor? How big is the number space?


Action 1:

Upon approval of this document, the IANA will create the
registry "RPC Program Numbers" at http://www.iana.org/assignments/TBD

0x00000000 Reserved
0x00000001 - 0x0001869f Reserved by previous assignments
0x000186a0 - 0x00061a7f Previous assignments
0x00061a80 - 0x1fffffff To be assigned by IANA
0x20000000 - 0x3fffffff Defined by local administrator
(some blocks assigned here)
0x40000000 - 0x5fffffff Transient
0x60000000 - 0x7effffff Reserved
0x7f000000 - 0x7fffffff Assignment outstanding
0x80000000 - 0xffffffff Reserved


Size of sub-block Assignment Method Authority
----------------- ----------------- ---------
Up to 100 numbers First Come First Served IANA
Up to 1000 numbers Specification Required IANA
More than 1000 numbers IESG Approval required IESG

Registration Procedures: Based on size of block
Initial contents of this registry will be:

< See contents of http://www.nfsv4-editor.org/rpc-numbers-1831bis.txt >


Action 2:

Upon approval of this document, the IANA will create the
registry "RPC Authentication Flavor Numbers" at
http://www.iana.org/assignments/TBD

Recent progress in RPC security has moved away from new auth flavors
as used by AUTH_DH [DH], and focused on using the existing RPCSEC_GSS
[RFC2203] flavor and inventing novel GSS-API mechanisms which can be
used with it. Even though RPCSEC_GSS is an assigned authentication
flavor, use of a new RPCSEC_GSS mechanism with NFS ([RFC1094]
[RFC1813] and [RFC3530]) will require the registration of 'pseudo-
flavors' which are used to negotiate security mechanisms in an
unambiguous way, as defined by [RFC2623]. Existing pseudo-flavors
have been granted in the decimal range 390000-390255. New pseudo-
flavor requests should be granted by IANA within this block on a
First Come First Served basis.

For non-pseudo-flavor requests, IANA should begin granting RPC
authentication flavor numbers at 400000 on a First Come First Served
basis to avoid conflicts with currently granted numbers.

For authentication flavors or RPCSEC_GSS mechanisms to be used on the
Internet, it is strongly advised that an informational or standards-
track RFC be published describing the authentication mechanism
behaviour and parameters.

Initial contents of this registry will be:

Auth Flavor Name Reference
------------ --------------------------- -----------------
0 AUTH_NONE [RFC-nfsv4-rfc1831bis-10]
1 AUTH_SYS [RFC-nfsv4-rfc1831bis-10]
2 AUTH_SHORT [RFC-nfsv4-rfc1831bis-10]
3 AUTH_DH [RFC-nfsv4-rfc1831bis-10]
6 RPCSEC_GSS [RFC-nfsv4-rfc1831bis-10]


We understand the above to be the only IANA Actions for this document.
2008-11-04
13 Amanda Baber
IANA Last Call comments:

IANA has questions:

- The document suggests that IANA start allocations at 0x00061a80, but
also states that previous assignments start at …
IANA Last Call comments:

IANA has questions:

- The document suggests that IANA start allocations at 0x00061a80, but
also states that previous assignments start at 0x000186a0. What about
0x00000001 - 0x0001869f? We've assumed those are reserved.

- The document suggests that a list of existing Authentication Flavors
and Pseudo-Flavors exists, but no such list is provided by value or
by reference in this document. Could you provide this list?

- In a similar vein, could you provide the allocation policy table
for the authentication flavor? How big is the number space?


Action 1:

Upon approval of this document, the IANA will create the
registry "RPC Program Numbers" at http://www.iana.org/assignments/TBD

0x00000000 Reserved
0x00000001 - 0x0001869f Reserved by previous assignments
0x000186a0 - 0x00061a7f Previous assignments
0x00061a80 - 0x1fffffff To be assigned by IANA
0x20000000 - 0x3fffffff Defined by local administrator
(some blocks assigned here)
0x40000000 - 0x5fffffff Transient
0x60000000 - 0x7effffff Reserved
0x7f000000 - 0x7fffffff Assignment outstanding
0x80000000 - 0xffffffff Reserved


Size of sub-block Assignment Method Authority
----------------- ----------------- ---------
Up to 100 numbers First Come First Served IANA
Up to 1000 numbers Specification Required IANA
More than 1000 numbers IESG Approval required IESG

Registration Procedures: Based on size of block
Initial contents of this registry will be:

< See contents of http://www.nfsv4-editor.org/rpc-numbers-1831bis.txt >


Action 2:

Upon approval of this document, the IANA will create the
registry "RPC Authentication Flavor Numbers" at
http://www.iana.org/assignments/TBD

Recent progress in RPC security has moved away from new auth flavors
as used by AUTH_DH [DH], and focused on using the existing RPCSEC_GSS
[RFC2203] flavor and inventing novel GSS-API mechanisms which can be
used with it. Even though RPCSEC_GSS is an assigned authentication
flavor, use of a new RPCSEC_GSS mechanism with NFS ([RFC1094]
[RFC1813] and [RFC3530]) will require the registration of 'pseudo-
flavors' which are used to negotiate security mechanisms in an
unambiguous way, as defined by [RFC2623]. Existing pseudo-flavors
have been granted in the decimal range 390000-390255. New pseudo-
flavor requests should be granted by IANA within this block on a
First Come First Served basis.

For non-pseudo-flavor requests, IANA should begin granting RPC
authentication flavor numbers at 400000 on a First Come First Served
basis to avoid conflicts with currently granted numbers.

For authentication flavors or RPCSEC_GSS mechanisms to be used on the
Internet, it is strongly advised that an informational or standards-
track RFC be published describing the authentication mechanism
behaviour and parameters.

Initial contents of this registry will be:

Auth Flavor Name Reference
------------ --------------------------- -----------------
0 AUTH_NONE [RFC-nfsv4-rfc1831bis-10]
1 AUTH_SYS [RFC-nfsv4-rfc1831bis-10]
2 AUTH_SHORT [RFC-nfsv4-rfc1831bis-10]
3 AUTH_DH [RFC-nfsv4-rfc1831bis-10]
6 RPCSEC_GSS [RFC-nfsv4-rfc1831bis-10]

We understand the above to be the only IANA Actions for this
document.
2008-10-30
13 Cindy Morgan Last call sent
2008-10-30
13 Cindy Morgan State Changes to In Last Call from Last Call Requested by Cindy Morgan
2008-10-30
13 Lars Eggert Placed on agenda for telechat - 2008-12-18 by Lars Eggert
2008-10-30
13 Lars Eggert State Changes to Last Call Requested from AD Evaluation::AD Followup by Lars Eggert
2008-10-30
13 Lars Eggert Last Call was requested by Lars Eggert
2008-10-30
13 (System) Ballot writeup text was added
2008-10-30
13 (System) Last call text was added
2008-10-30
13 (System) Ballot approval text was added
2008-10-30
13 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-10-30
10 (System) New version available: draft-ietf-nfsv4-rfc1831bis-10.txt
2008-08-11
13 Lars Eggert State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Lars Eggert
2008-08-11
13 Lars Eggert [Note]: 'Document Shepherd: Spencer Shepler (spencer.shepler@gmail.com)' added by Lars Eggert
2008-08-11
13 Lars Eggert Haven't received an interop report yet - need to see one before I can LC a DS.
2008-08-11
13 Lars Eggert State Change Notice email list have been change to nfsv4-chairs@tools.ietf.org, draft-ietf-nfsv4-rfc1831bis@tools.ietf.org from nfsv4-chairs@tools.ietf.org
2008-08-11
13 Lars Eggert State Changes to AD Evaluation from Publication Requested by Lars Eggert
2008-07-28
13 Cindy Morgan Intended Status has been changed to Draft Standard from None
2008-07-28
13 Cindy Morgan State Changes to Publication Requested from AD is watching by Cindy Morgan
2008-07-28
13 Cindy Morgan
(1.a) Who is the Document Shepherd For this document? Has the
Document Shepherd personally reviewed this version of the
document
and, in particular, does he …
(1.a) Who is the Document Shepherd For this document? Has the
Document Shepherd personally reviewed this version of the
document
and, in particular, does he or she believe this version is ready
for forwarding to the IESG for publication?

The document shepherd is Spencer Shepler. Spencer has reviewed
the documents and believes they are ready for publication.

(1.b) Has the document had adequate review both from key members of
the interested community and others? Does the Document Shepherd
have any concerns about the depth or breadth of the reviews that
have been performed?

Yes. Reviews and last calls have been done at least twice with
this document. The shepherd does not have any issues with the
review; this is an update of an existing RFC and the scope of
the updates have been very limited.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective, e.g.,
security, operational complexity, someone familiar with AAA,
internationalization or XML?

No concerns.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or
she is uncomfortable with certain parts of the document, or has
concerns whether there really is a need for it. In any event, if
the interested community has discussed those issues and has
indicated that it still wishes to advance the document, detail
those concerns here.

No concerns.

(1.e) How solid is the consensus of the interested community behind
this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the interested
community as a whole understand and agree with it?

Strong consensus is held.

(1.f) Has anyone threatened an appeal or otherwise indicated
extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough. Has the document met
all
formal review criteria it needs to, such as the MIB Doctor, media
type and URI type reviews?

Yes.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are
not ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the strategy for
their
completion? Are there normative references that are downward
references, as described in [RFC3967]? If so, list these
downward
references to support the Area Director in the Last Call
procedure
for them [RFC3967].

Yes.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of
the document?

Yes.

If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries?

N/A

Are the IANA registries clearly identified?

Yes.

If the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations?

Yes.

Does it suggested a reasonable name for the new registry?

Yes.

If the document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

N/A

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML code,
BNF rules, MIB definitions, etc., validate correctly in an
automated checker?

Yes.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document is intended to replace RFC 1831 as the
authoritative document describing RPC, without introducing
any over-the-wire protocol changes. The update includes
transition of the RPC program and authentication registries
to IANA along with appropriate rules for new entry requests.
It also provides additional discussion the the security
considerations section based on experience with strong
security flavors.

Working Group Summary

There is a long implementation history of this protocol and
the main intent of this document update is to move the RPC
RFC to Draft Standard. There has been strong support of this
within the RPC community and specifically within the working
group.

Document Quality

Given the review time, the numerous implementations in
existence and the updates that have been done, the quality of
this document is high.
2008-06-10
09 (System) New version available: draft-ietf-nfsv4-rfc1831bis-09.txt
2008-02-22
08 (System) New version available: draft-ietf-nfsv4-rfc1831bis-08.txt
2008-01-31
13 (System) State Changes to AD is watching from Dead by system
2008-01-30
07 (System) New version available: draft-ietf-nfsv4-rfc1831bis-07.txt
2007-06-30
13 (System) State Changes to Dead from AD is watching by system
2007-06-30
13 (System) Document has expired
2007-01-18
13 Lars Eggert Draft Added by Lars Eggert in state AD is watching
2006-12-27
06 (System) New version available: draft-ietf-nfsv4-rfc1831bis-06.txt
2005-02-04
05 (System) New version available: draft-ietf-nfsv4-rfc1831bis-05.txt
2004-09-20
04 (System) New version available: draft-ietf-nfsv4-rfc1831bis-04.txt
2004-06-28
03 (System) New version available: draft-ietf-nfsv4-rfc1831bis-03.txt
2004-05-28
02 (System) New version available: draft-ietf-nfsv4-rfc1831bis-02.txt
2003-08-29
01 (System) New version available: draft-ietf-nfsv4-rfc1831bis-01.txt
2003-05-20
00 (System) New version available: draft-ietf-nfsv4-rfc1831bis-00.txt