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 | |
|
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 <insert list here>. 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 |