Re: [nfsv4] AD review: draft-ietf-nfsv4-rfc1831bis-09

Hi,

thank you for the draft update. Can you please submit it so I can  
start IESG evaluation?

Also, thanks for the interoperability report. I'll upload it to where  
it needs to go.

Lars

On 2008-10-25, at 0:26, ext Robert Thurlow wrote:

> Lars Eggert wrote:
>> INTRODUCTION, paragraph 1:
>> > Intended status: Draft Standard
>>  IETF rules don't allow me to progress this before having received  
>> the
>>  interop report that is required when moving from Proposed to Draft
>>  Standard. Please send that ASAP.
>
> Lars,
>
> Apologies for the delay, attached is an implementation report for RPC.
>
>> INTRODUCTION, paragraph 12:
>> >    This document describes the ONC (Open Network Computing) Remote
>> >    Procedure Call (ONC RPC Version 2) protocol as it is currently
>> >    deployed and accepted.  It is meant to supersede [RFC1831].
>>  Suggest to change "is meant to supersede" to "obsoletes", to use the
>>  normal IETF terminology.
>
> Fixed.
>
>> INTRODUCTION, paragraph 13:
>> >    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL  
>> NOT",
>> >    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"  
>> in this
>> >    document are to be interpreted as described in [RFC2119].
>>  This paragraph is not typically found within the abstract. Suggest  
>> to
>>  move it to the introduction or the terminology section.
>
> I kept this in the same location (between abstract and contents)
> and added a header to make this look like the current NFSv4.1 draft.
>
>> Section 2., paragraph 1:
>> >    This document is intended to replace RFC 1831 as the  
>> authoritative
>> >    document describing RPC, without introducing any over-the-wire
>> >    protocol changes.
>>  Change "is intended to replace" to "obsoletes".
>
> Fixed.
>
>> Section 13.2., paragraph 1:
>> >    Sun has made assignments in both number spaces since the  
>> original
>> >    deployment of RPC.  The assignments made by Sun Microsystems are
>> >    still valid, and will be preserved.  Sun will communicate all  
>> current
>> >    assignments in both number spaces to IANA before final handoff  
>> of
>> >    number assignment is done.
>>  If the Sun registry is publicly available, please provide a pointer,
>>  so that IANA can take a look at what is currently there.
>
> We have the current assignments public now, thanks to Spencer:
> http://www.nfsv4-editor.org/rpc-numbers-1831bis.txt
> I put this in Section 13.2, Protecting Past Assignments".
>
>> Section 13.3., paragraph 0:
>> > 13.3.  RPC Number Assignment
>>  This section doesn't describe what the registry looks like. Section
>>  8.3 only contains a table of numbers, but Appendix B asks for a lot
>>  more information that looks like it should go into the registry
>>  ("identifier string", assignee, description, etc.) This section also
>>  doesn't describe what the initial assignments in the registry are.
>
> I have added detail about what IANA should do with the original
> request, and what should be placed in the public registry.  I
> expect that the following section, "Protecting Past Assignments",
> should cover initial assignments.
>
>> Section 13.3.5., paragraph 7:
>> >    Sub-blocks sized over 1000 numbers must be documented as  
>> described
>> >    above, however an Internet Draft must be submitted as an
>> >    Informational or standards-track RFC.
>>  This paragraph isn't aligned with the table above, which says that  
>> the
>>  assignment method is "IESG Approval". Please check RFC5226 for the
>>  definitions and pick one.
>
> I have reworded this to be consistent with IESG Approval.
>
>> Section 13.3.5., paragraph 11:
>> >    If an individual or entity has under 1000 numbers and later  
>> requests
>> >    an additional set of numbers such that the individual or  
>> entity would
>> >    over 1000 numbers, then the individual or entity will have the
>> >    additional request submitted to the IESG.  IESG is free to  
>> waive the
>> >    IESG Action Required assignment method for incremental  
>> requests of
>> >    less than 1000 numbers.
>>  RFC5226 doesn't define a policy called "IESG Action Required" - I
>>  guess what's meant here is "IESG Approval". Also, the IESG giving  
>> out
>>  a waiver is identical to the IESG approving the request, so I don't
>>  think this needs to be described differently.
>
> I have reworded this to simply state IESG Approval is required.
>
>> Section 13.4., paragraph 0:
>> > 13.4.  RPC Authentication Flavor Number Assignment
>>  This section doesn't describe what the "flavor" registry looks like,
>>  what it's initial allocations are or what RFC5226 policy IANA should
>>  use for future assignments.
>
> I have added language akin to what I added for 13.3 for auth numbers,
> describing what IANA should do with requests and what it should place
> in the public registry, and that the policy should be First Come First
> Served.
>
> An amended draft is attached; please review the changes, and I will
> resubmit it.
>
> Thanks,
> Rob T
> RPC implementation report in support of advancing RPC (RFC1831) to DS
>
> Feature list from spec:
> RPC over UDP
> RPC over TCP
> Program number matching
> Version number matching
> Procedure number matching
> Transaction ID matching
> AUTH_NONE
> AUTH_SYS
> AUTH_DH
> RPCSEC_GSS
>
> Name of Implementation: Solaris Nevada's RPC/XDR
> Organization/Vendor: Sun Microsystems, Inc.
> Implemented features: all
> Platforms: Solaris SPARC, Solaris x86
> Lineage of code: Based on the first RPC/XDR implemenation (circa) 1984
> for Sun's SunOS 2.0/mc68k platform by Bob Lyon.  Much of the code is
> still similar. Sun has extended it to support things such as  
> RPCSEC_GSS
> and RDMA.
> Point of Contact: Rob Thurlow (Robert.Thurlow@sun.com), code available
> via http://opensolaris.org/os/downloads
> Claimed Interoperability: The code is tested annually at Connectathon,
> in which dozens of implementors test interoperability of NFS, NIS,
> NIS+, and RPC/XDR. NFS, NIS, NIS+ all use RPC/XDR. Connectathon has
> been an annual affair since 1985 (one year in the 90s was skipped).
> Implementors at Connectathon have included: Sun, Pyramid, Gould  
> Computer,
> MIPS, SGI, Sun's PC-NFS group, IBM, Digital Equipment, HP, FTP  
> Software.
> Report By: Rob Thurlow
>
> Name of Implementation: FreeBSD's kernel RPC code in NFS
> Organization/Vendor: Rick Macklem
> Implemented features: all except AUTH_DH
> Platforms: FreeBSD on x86
> Lineage of code: This is an independent implementation, inlining
> RPC and other protocol elements directly into mbufs
> Point of Contact: Rick Macklem (rmacklem@uoguelph.ca), code available
> via ftp://ftp.cis.uoguelph.ca/pub/nfsv4/FreeBSD-CURRENT
> Claimed Interoperability: Rick has brought his code to numerous
> Connectathon events; this code is also the basis for NFS support
> in other BSD releases, including MacOS X's NFS code.
> Report By: Rob Thurlow
>
> Name of Implementation: ILU Sun RPC support
> Organization/Vendor: Xerox/PARC
> Implemented features: all except AUTH_DH, RPCSEC_GSS and RPC over UDP
> Platforms: Byte addressable ANSI C systems.
> Lineage of code: Original, from RFC 1831.
> Point of Contact: ilu-core@parc.xerox.com, code available via
> ftp://ftp.parc.xerox.com/pub/ilu/ilu.html.
> Claimed Interoperability: ILU project has verified interoperability
> (on the subset of functionality implemented) on various platforms
> with Sun's standard implementation.
> Report By: Rob Thurlow
>
>
>
>
>
>
> Network File System Version 4 Working Group                   R.  
> Thurlow
> Internet-Draft                                          Sun  
> Microsystems
> Intended status: Draft Standard
> Obsoletes: 1831
> Expires: April 24, 2009                               October 24, 2008
>
>
>      RPC: Remote Procedure Call Protocol Specification Version 2
>                   draft-ietf-nfsv4-rfc1831bis-10.txt
>
> Status of this Memo
>
>   By submitting this Internet-Draft, each author represents that any
>   applicable patent or other IPR claims of which he or she is aware
>   have been or will be disclosed, and any of which he or she becomes
>   aware will be disclosed, in accordance with Section 6 of BCP 79.
>
>   Internet-Drafts are working documents of the Internet Engineering
>   Task Force (IETF), its areas, and its working groups.  Note that
>   other groups may also distribute working documents as Internet-
>   Drafts.
>
>   Internet-Drafts are draft documents valid for a maximum of six  
> months
>   and may be updated, replaced, or obsoleted by other documents at any
>   time.  It is inappropriate to use Internet-Drafts as reference
>   material or to cite them other than as "work in progress."
>
>   The list of current Internet-Drafts can be accessed at
>   http://www.ietf.org/1id-abstracts.html
>
>   The list of Internet-Draft Shadow Directories can be accessed at
>   http://www.ietf.org/shadow.html
>
>   Discussion and suggestions for improvement are requested.  This
>   document will expire in April, 2009. Distribution of this draft is
>   unlimited.
>
> Abstract
>
>   This document describes the ONC (Open Network Computing) Remote
>   Procedure Call (ONC RPC Version 2) protocol as it is currently
>   deployed and accepted.  This document obsoletes [RFC1831].
>
> Requirements Language
>
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in [RFC2119].
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt            
> [Page 1]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
> Table of Contents
>
>   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
>   2.  Changes since RFC 1831 . . . . . . . . . . . . . . . . . . . 1
>   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . 1
>   4.  The RPC Model  . . . . . . . . . . . . . . . . . . . . . . . 1
>   5.  Transports and Semantics . . . . . . . . . . . . . . . . . . 1
>   6.  Binding and Rendezvous Independence  . . . . . . . . . . . . 1
>   7.  Authentication . . . . . . . . . . . . . . . . . . . . . . . 1
>   8.  RPC Protocol Requirements  . . . . . . . . . . . . . . . . . 1
>   8.1.  RPC Programs and Procedures  . . . . . . . . . . . . . . . 1
>   8.2.  Authentication, Integrity and Privacy  . . . . . . . . . . 1
>   8.3.  Program Number Assignment  . . . . . . . . . . . . . . . . 1
>   8.4.  Other Uses of the RPC Protocol . . . . . . . . . . . . . . 1
>   8.4.1.  Batching . . . . . . . . . . . . . . . . . . . . . . . . 1
>   8.4.2.  Broadcast Remote Procedure Calls . . . . . . . . . . . . 1
>   9.  The RPC Message Protocol . . . . . . . . . . . . . . . . . . 1
>   10.  Authentication Protocols  . . . . . . . . . . . . . . . . . 1
>   10.1.  Null Authentication . . . . . . . . . . . . . . . . . . . 1
>   11.  Record Marking Standard . . . . . . . . . . . . . . . . . . 1
>   12.  The RPC Language  . . . . . . . . . . . . . . . . . . . . . 1
>   12.1.  An Example Service Described in the RPC Language  . . . . 1
>   12.2.  The RPC Language Specification  . . . . . . . . . . . . . 1
>   12.3.  Syntax Notes  . . . . . . . . . . . . . . . . . . . . . . 1
>   13.  IANA Considerations . . . . . . . . . . . . . . . . . . . . 1
>   13.1.  Numbering Requests to IANA  . . . . . . . . . . . . . . . 1
>   13.2.  Protecting Past Assignments . . . . . . . . . . . . . . . 1
>   13.3.  RPC Number Assignment . . . . . . . . . . . . . . . . . . 1
>   13.3.1.  To be assigned by IANA  . . . . . . . . . . . . . . . . 1
>   13.3.2.  Defined by local administrator  . . . . . . . . . . . . 1
>   13.3.3.  Transient block . . . . . . . . . . . . . . . . . . . . 1
>   13.3.4.  Reserved block  . . . . . . . . . . . . . . . . . . . . 1
>   13.3.5.  RPC Number Sub-Blocks . . . . . . . . . . . . . . . . . 1
>   13.4.  RPC Authentication Flavor Number Assignment . . . . . . . 1
>   13.4.1.  Assignment Policy . . . . . . . . . . . . . . . . . . . 1
>   13.4.2.  Auth Flavors vs. Pseudo-flavors . . . . . . . . . . . . 1
>   14.  Security Considerations . . . . . . . . . . . . . . . . . . 1
>   15.  Appendix A: System Authentication . . . . . . . . . . . . . 1
>   16.  Appendix B: Requesting RPC program or authentication
>        numbers . . . . . . . . . . . . . . . . . . . . . . . . . . 1
>   17.  Full Copyright Statement  . . . . . . . . . . . . . . . . . 1
>   18.  Intellectual property . . . . . . . . . . . . . . . . . . . 1
>   19.  Acknowledgment  . . . . . . . . . . . . . . . . . . . . . . 1
>   20.  Normative References  . . . . . . . . . . . . . . . . . . . 1
>   21.  Informative References  . . . . . . . . . . . . . . . . . . 1
>   22.  Author's Address  . . . . . . . . . . . . . . . . . . . . . 1
>
>
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt            
> [Page 2]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
> 1.  Introduction
>
>   This document specifies version two of the message protocol used in
>   ONC Remote Procedure Call (RPC).  The message protocol is specified
>   with the eXternal Data Representation (XDR) language [RFC4506].   
> This
>   document assumes that the reader is familiar with XDR.  It does not
>   attempt to justify remote procedure calls systems or describe their
>   use.  The paper by Birrell and Nelson [XRPC] is recommended as an
>   excellent background for the remote procedure call concept.
>
> 2.  Changes since RFC 1831
>
>   This document obsoletes RFC 1831 as the authoritative document
>   describing RPC, without introducing any over-the-wire protocol
>   changes.  The main changes from RFC 1831 are:
>
>   o    Addition of an Appendix which describes how an implementor can
>        request new RPC program numbers and authentication flavor
>        numbers from IANA, rather than from Sun Microsystems
>
>   o    Addition of an "IANA Considerations" section which describes
>        past program and authentication flavor number assignment policy
>        and how IANA is intended to assign them in future
>
>   o    Clarification of the RPC Language Specification to match  
> current
>        usage
>
>   o    Enhancement of the "Security Considerations" section to reflect
>        experience with strong security flavors
>
>   o    Specification of new authentication errors that are in common
>        use in modern RPC implementations
>
>   o    Updates for the latest IETF intellectual property statements
>
> 3.  Terminology
>
>   This document discusses clients, calls, servers, replies, services,
>   programs, procedures, and versions.  Each remote procedure call has
>   two sides: an active client side that makes the call to a server,
>   which sends back a reply.  A network service is a collection of one
>   or more remote programs.  A remote program implements one or more
>   remote procedures; the procedures, their parameters, and results are
>   documented in the specific program's protocol specification.  A
>   server may support more than one version of a remote program in  
> order
>   to be compatible with changing protocols.
>
>   For example, a network file service may be composed of two programs.
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt            
> [Page 3]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
>   One program may deal with high-level applications such as file  
> system
>   access control and locking.  The other may deal with low-level file
>   input and output and have procedures like "read" and "write".  A
>   client of the network file service would call the procedures
>   associated with the two programs of the service on behalf of the
>   client.
>
>   The terms client and server only apply to a particular  
> transaction; a
>   particular hardware entity (host) or software entity (process or
>   program) could operate in both roles at different times.  For
>   example, a program that supplies remote execution service could also
>   be a client of a network file service.
>
> 4.  The RPC Model
>
>   The ONC RPC protocol is based on the remote procedure call model,
>   which is similar to the local procedure call model.  In the local
>   case, the caller places arguments to a procedure in some well-
>   specified location (such as a register window).  It then transfers
>   control to the procedure, and eventually regains control.  At that
>   point, the results of the procedure are extracted from the well-
>   specified location, and the caller continues execution.
>
>   The remote procedure call model is similar.  One thread of control
>   logically winds through two processes: the caller's process, and a
>   server's process.  The caller process first sends a call message to
>   the server process and waits (blocks) for a reply message.  The call
>   message includes the procedure's parameters, and the reply message
>   includes the procedure's results.  Once the reply message is
>   received, the results of the procedure are extracted, and caller's
>   execution is resumed.
>
>   On the server side, a process is dormant awaiting the arrival of a
>   call message.  When one arrives, the server process extracts the
>   procedure's parameters, computes the results, sends a reply message,
>   and then awaits the next call message.
>
>   In this model, only one of the two processes is active at any given
>   time.  However, this model is only given as an example.  The ONC RPC
>   protocol makes no restrictions on the concurrency model implemented,
>   and others are possible.  For example, an implementation may choose
>   to have RPC calls be asynchronous, so that the client may do useful
>   work while waiting for the reply from the server.  Another
>   possibility is to have the server create a separate task to process
>   an incoming call, so that the original server can be free to receive
>   other requests.
>
>
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt            
> [Page 4]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
>   There are a few important ways in which remote procedure calls  
> differ
>   from local procedure calls:
>
>   o    Error handling: failures of the remote server or network must  
> be
>        handled when using remote procedure calls.
>
>   o    Global variables and side-effects: since the server does not
>        have access to the client's address space, hidden arguments
>        cannot be passed as global variables or returned as side
>        effects.
>
>   o    Performance:  remote procedures usually operate one or more
>        orders of magnitude slower than local procedure calls.
>
>   o    Authentication: since remote procedure calls can be transported
>        over unsecured networks, authentication may be necessary.
>        Authentication prevents one entity from masquerading as some
>        other entity.
>
>   The conclusion is that even though there are tools to automatically
>   generate client and server libraries for a given service, protocols
>   must still be designed carefully.
>
> 5.  Transports and Semantics
>
>   The RPC protocol can be implemented on several different transport
>   protocols.  The scope of the definition of the RPC protocol excludes
>   how a message is passed from one process to another, and includes
>   only the specification and interpretation of messages.  However, the
>   application may wish to obtain information about (and perhaps  
> control
>   over) the transport layer through an interface not specified in this
>   document.  For example, the transport protocol may impose a
>   restriction on the maximum size of RPC messages, or it may be
>   stream-oriented like TCP [RFC793] with no size limit.  The client  
> and
>   server must agree on their transport protocol choices.
>
>   It is important to point out that RPC does not try to implement any
>   kind of reliability and that the application may need to be aware of
>   the type of transport protocol underneath RPC.  If it knows it is
>   running on top of a reliable transport such as TCP, then most of the
>   work is already done for it.  On the other hand, if it is running on
>   top of an unreliable transport such as UDP [RFC768], it must
>   implement its own time-out, retransmission, and duplicate detection
>   policies as the RPC protocol does not provide these services.
>
>   Because of transport independence, the RPC protocol does not attach
>   specific semantics to the remote procedures or their execution
>   requirements.  Semantics can be inferred from (but should be
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt            
> [Page 5]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
>   explicitly specified by) the underlying transport protocol.  For
>   example, consider RPC running on top of an unreliable transport such
>   as UDP.  If an application retransmits RPC call messages after time-
>   outs, and does not receive a reply, it cannot infer anything about
>   the number of times the procedure was executed.  If it does  
> receive a
>   reply, then it can infer that the procedure was executed at least
>   once.
>
>   A server may wish to remember previously granted requests from a
>   client and not regrant them in order to insure some degree of
>   execute-at-most-once semantics.  A server can do this by taking
>   advantage of the transaction ID that is packaged with every RPC
>   message.  The main use of this transaction ID is by the client RPC
>   entity in matching replies to calls.  However, a client application
>   may choose to reuse its previous transaction ID when  
> retransmitting a
>   call.  The server may choose to remember this ID after executing a
>   call and not execute calls with the same ID in order to achieve some
>   degree of execute-at-most-once semantics.  The server is not allowed
>   to examine this ID in any other way except as a test for equality.
>
>   On the other hand, if using a "reliable" transport such as TCP, the
>   application can infer from a reply message that the procedure was
>   executed exactly once, but if it receives no reply message, it  
> cannot
>   assume that the remote procedure was not executed.  Note that even  
> if
>   a connection-oriented protocol like TCP is used, an application  
> still
>   needs time-outs and reconnection to handle server crashes.
>
>   There are other possibilities for transports besides datagram- or
>   connection-oriented protocols.  For example, a request-reply  
> protocol
>   such as [VMTP] is perhaps a natural transport for RPC.  ONC RPC
>   currently uses both TCP and UDP transport protocols.  Section 10
>   (Record Marking Standard) describes the mechanism employed by ONC  
> RPC
>   to utilize a connection-oriented, stream-oriented transport such as
>   TCP.  The mechanism by which future transports having different
>   structural characteristics should be used to transfer ONC RPC
>   messages should be specified by means of a standards-track RFC, once
>   such additional transports are defined.
>
> 6.  Binding and Rendezvous Independence
>
>   The act of binding a particular client to a particular service and
>   transport parameters is NOT part of this RPC protocol specification.
>   This important and necessary function is left up to some higher- 
> level
>   software.
>
>   Implementors could think of the RPC protocol as the jump-subroutine
>   instruction ("JSR") of a network; the loader (binder) makes JSR
>   useful, and the loader itself uses JSR to accomplish its task.
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt            
> [Page 6]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
>   Likewise, the binding software makes RPC useful, possibly using RPC
>   to accomplish this task.
>
> 7.  Authentication
>
>   The RPC protocol provides the fields necessary for a client to
>   identify itself to a service, and vice-versa, in each call and reply
>   message.  Security and access control mechanisms can be built on top
>   of this message authentication.  Several different authentication
>   protocols can be supported.  A field in the RPC header indicates
>   which protocol is being used. More information on specific
>   authentication protocols is in section 8.2: "Authentication,
>   Integrity and Privacy".
>
> 8.  RPC Protocol Requirements
>
>   The RPC protocol must provide for the following:
>
>   o    Unique specification of a procedure to be called.
>
>   o    Provisions for matching response messages to request messages.
>
>   o    Provisions for authenticating the caller to service and vice-
>        versa.
>
>   Besides these requirements, features that detect the following are
>   worth supporting because of protocol roll-over errors,  
> implementation
>   bugs, user error, and network administration:
>
>   o    RPC protocol mismatches.
>
>   o    Remote program protocol version mismatches.
>
>   o    Protocol errors (such as misspecification of a procedure's
>        parameters).
>
>   o    Reasons why remote authentication failed.
>
>   o    Any other reasons why the desired procedure was not called.
>
>
> 8.1.  RPC Programs and Procedures
>
>   The RPC call message has three unsigned integer fields -- remote
>   program number, remote program version number, and remote procedure
>   number -- which uniquely identify the procedure to be called.
>   Program numbers are administered by a central authority (IANA).   
> Once
>   implementors have a program number, they can implement their remote
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt            
> [Page 7]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
>   program; the first implementation would most likely have the version
>   number 1 but MUST NOT be the number zero.  Because most new  
> protocols
>   evolve, a version field of the call message identifies which version
>   of the protocol the caller is using.  Version numbers enable support
>   of both old and new protocols through the same server process.
>
>   The procedure number identifies the procedure to be called.  These
>   numbers are documented in the specific program's protocol
>   specification.  For example, a file service's protocol specification
>   may state that its procedure number 5 is "read" and procedure number
>   12 is "write".
>
>   Just as remote program protocols may change over several versions,
>   the actual RPC message protocol could also change.  Therefore, the
>   call message also has in it the RPC version number, which is always
>   equal to two for the version of RPC described here.
>
>   The reply message to a request message has enough information to
>   distinguish the following error conditions:
>
>   o    The remote implementation of RPC does not support protocol
>        version 2.  The lowest and highest supported RPC version  
> numbers
>        are returned.
>
>   o    The remote program is not available on the remote system.
>
>   o    The remote program does not support the requested version
>        number.  The lowest and highest supported remote program  
> version
>        numbers are returned.
>
>   o    The requested procedure number does not exist.  (This is  
> usually
>        a client side protocol or programming error.)
>
>   o    The parameters to the remote procedure appear to be garbage  
> from
>        the server's point of view.  (Again, this is usually caused  
> by a
>        disagreement about the protocol between client and service.)
>
>
> 8.2.  Authentication, Integrity and Privacy
>
>   Provisions for authentication of caller to service and vice-versa  
> are
>   provided as a part of the RPC protocol.  The call message has two
>   authentication fields, the credential and verifier.  The reply
>   message has one authentication field, the response verifier.  The  
> RPC
>   protocol specification defines all three fields to be the following
>   opaque type (in the eXternal Data Representation (XDR) language
>   [RFC4506]):
>
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt            
> [Page 8]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
>         enum auth_flavor {
>            AUTH_NONE       = 0,
>            AUTH_SYS        = 1,
>            AUTH_SHORT      = 2,
>            AUTH_DH         = 3,
>            RPCSEC_GSS      = 6
>            /* and more to be defined */
>         };
>
>         struct opaque_auth {
>            auth_flavor flavor;
>            opaque body<400>;
>         };
>
>   In other words, any "opaque_auth" structure is an "auth_flavor"
>   enumeration followed by up to 400 bytes which are opaque to
>   (uninterpreted by) the RPC protocol implementation.
>
>   The interpretation and semantics of the data contained within the
>   authentication fields is specified by individual, independent
>   authentication protocol specifications.
>
>   If authentication parameters were rejected, the reply message
>   contains information stating why they were rejected.
>
>   As demonstrated by  RPCSEC_GSS, it is possible for an "auth_flavor"
>   to also support integrity and privacy.
>
> 8.3.  Program Number Assignment
>
>   Program numbers are given out in groups of hexadecimal 20000000
>   (decimal 536870912) according to the following chart:
>
>              0x00000000                Reserved
>              0x00000001 - 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
>
>   The first group is a range of numbers administered by IANA and  
> should
>   be identical for all sites.  The second range is for applications
>   peculiar to a particular site.  This range is intended primarily for
>   debugging new programs.  When a site develops an application that
>   might be of general interest, that application should be given an
>   assigned number in the first range.  Application developers may  
> apply
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt            
> [Page 9]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
>   for blocks of RPC program numbers in the first range by methods
>   described in Appendix B.  The third group is for applications that
>   generate program numbers dynamically.  The final groups are reserved
>   for future use, and should not be used.
>
> 8.4.  Other Uses of the RPC Protocol
>
>   The intended use of this protocol is for calling remote procedures.
>   Normally, each call message is matched with a reply message.
>   However, the protocol itself is a message-passing protocol with  
> which
>   other (non-procedure call) protocols can be implemented.
>
> 8.4.1.  Batching
>
>   Batching is useful when a client wishes to send an arbitrarily large
>   sequence of call messages to a server.  Batching typically uses
>   reliable byte stream protocols (like TCP) for its transport.  In the
>   case of batching, the client never waits for a reply from the  
> server,
>   and the server does not send replies to batch calls.  A sequence of
>   batch calls is usually terminated by a legitimate remote procedure
>   call operation in order to flush the pipeline and get positive
>   acknowledgement.
>
> 8.4.2.  Broadcast Remote Procedure Calls
>
>   In broadcast protocols, the client sends a broadcast call to the
>   network and waits for numerous replies.  This requires the use of
>   packet-based protocols (like UDP) as its transport protocol.   
> Servers
>
>   that support broadcast protocols usually respond only when the call
>   is successfully processed and are silent in the face of errors, but
>   this varies with the application.
>
>   The principles of broadcast RPC also apply to multicasting - an RPC
>   request can be sent to a multicast address.
>
> 9.  The RPC Message Protocol
>
>   This section defines the RPC message protocol in the XDR data
>   description language [RFC4506].
>
>         enum msg_type {
>            CALL  = 0,
>            REPLY = 1
>         };
>
>   A reply to a call message can take on two forms: The message was
>   either accepted or rejected.
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt          [Page  
> 10]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
>         enum reply_stat {
>            MSG_ACCEPTED = 0,
>            MSG_DENIED   = 1
>         };
>
>   Given that a call message was accepted, the following is the status
>   of an attempt to call a remote procedure.
>
>         enum accept_stat {
>            SUCCESS       = 0, /* RPC executed successfully       */
>            PROG_UNAVAIL  = 1, /* remote hasn't exported program  */
>            PROG_MISMATCH = 2, /* remote can't support version #  */
>            PROC_UNAVAIL  = 3, /* program can't support procedure */
>            GARBAGE_ARGS  = 4, /* procedure can't decode params   */
>            SYSTEM_ERR    = 5  /* e.g. memory allocation failure  */
>         };
>
>   Reasons why a call message was rejected:
>
>         enum reject_stat {
>            RPC_MISMATCH = 0, /* RPC version number != 2          */
>            AUTH_ERROR = 1    /* remote can't authenticate caller */
>         };
>
>   Why authentication failed:
>
>         enum auth_stat {
>            AUTH_OK           = 0,  /* success                         
> */
>            /*
>             * failed at remote end
>             */
>            AUTH_BADCRED      = 1,  /* bad credential (seal broken)    
> */
>            AUTH_REJECTEDCRED = 2,  /* client must begin new session   
> */
>            AUTH_BADVERF      = 3,  /* bad verifier (seal broken)      
> */
>            AUTH_REJECTEDVERF = 4,  /* verifier expired or replayed    
> */
>            AUTH_TOOWEAK      = 5,  /* rejected for security reasons   
> */
>            /*
>             * failed locally
>             */
>            AUTH_INVALIDRESP  = 6,  /* bogus response verifier         
> */
>            AUTH_FAILED       = 7,  /* reason unknown                  
> */
>            /*
>             * AUTH_KERB errors; deprecated. See [RFC2695]
>             */
>            AUTH_KERB_GENERIC = 8,  /* kerberos generic error */
>            AUTH_TIMEEXPIRE = 9,    /* time of credential expired */
>            AUTH_TKT_FILE = 10,     /* problem with ticket file */
>            AUTH_DECODE = 11,       /* can't decode authenticator */
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt          [Page  
> 11]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
>            AUTH_NET_ADDR = 12,     /* wrong net address in ticket */
>            /*
>             * RPCSEC_GSS GSS related errors
>             */
>            RPCSEC_GSS_NOCRED = 13,  /* no credentials for user */
>            RPCSEC_GSS_FAILED = 14   /* GSS failure, creds deleted */
>         };
>
>   The RPC message:
>
>   All messages start with a transaction identifier, xid, followed by a
>   two-armed discriminated union.  The union's discriminant is a
>   msg_type which switches to one of the two types of the message.  The
>   xid of a REPLY message always matches that of the initiating CALL
>   message.  NB: The xid field is only used for clients matching reply
>   messages with call messages or for servers detecting  
> retransmissions;
>   the service side cannot treat this id as any type of sequence  
> number.
>
>         struct rpc_msg {
>            unsigned int xid;
>            union switch (msg_type mtype) {
>            case CALL:
>               call_body cbody;
>            case REPLY:
>               reply_body rbody;
>            } body;
>         };
>
>
>   Body of an RPC call:
>
>   In version 2 of the RPC protocol specification, rpcvers MUST be  
> equal
>   to 2.  The fields prog, vers, and proc specify the remote program,
>   its version number, and the procedure within the remote program to  
> be
>   called.  After these fields are two authentication parameters:  cred
>   (authentication credential) and verf (authentication verifier).  The
>   two authentication parameters are followed by the parameters to the
>   remote procedure, which are specified by the specific program
>   protocol.
>
>   The purpose of the authentication verifier is to validate the
>   authentication credential.  Note that these two items are
>   historically separate, but are always used together as one logical
>   entity.
>
>         struct call_body {
>            unsigned int rpcvers;       /* must be equal to two (2) */
>            unsigned int prog;
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt          [Page  
> 12]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
>            unsigned int vers;
>            unsigned int proc;
>            opaque_auth cred;
>            opaque_auth verf;
>            /* procedure specific parameters start here */
>         };
>
>   Body of a reply to an RPC call:
>
>         union reply_body switch (reply_stat stat) {
>         case MSG_ACCEPTED:
>            accepted_reply areply;
>         case MSG_DENIED:
>            rejected_reply rreply;
>         } reply;
>
>   Reply to an RPC call that was accepted by the server:
>
>   There could be an error even though the call was accepted.  The  
> first
>   field is an authentication verifier that the server generates in
>   order to validate itself to the client.  It is followed by a union
>   whose discriminant is an enum accept_stat.  The SUCCESS arm of the
>   union is protocol specific.  The PROG_UNAVAIL, PROC_UNAVAIL,
>   GARBAGE_ARGS, and SYSTEM_ERR arms of the union are void.  The
>   PROG_MISMATCH arm specifies the lowest and highest version numbers  
> of
>   the remote program supported by the server.
>
>         struct accepted_reply {
>            opaque_auth verf;
>            union switch (accept_stat stat) {
>            case SUCCESS:
>               opaque results[0];
>               /*
>                * procedure-specific results start here
>                */
>             case PROG_MISMATCH:
>                struct {
>                   unsigned int low;
>                   unsigned int high;
>                } mismatch_info;
>             default:
>                /*
>                 * Void.  Cases include PROG_UNAVAIL, PROC_UNAVAIL,
>                 * GARBAGE_ARGS, and SYSTEM_ERR.
>                 */
>                void;
>             } reply_data;
>         };
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt          [Page  
> 13]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
>   Reply to an RPC call that was rejected by the server:
>
>   The call can be rejected for two reasons: either the server is not
>   running a compatible version of the RPC protocol (RPC_MISMATCH), or
>   the server rejects the identity of the caller (AUTH_ERROR). In case
>   of an RPC version mismatch, the server returns the lowest and  
> highest
>   supported RPC version numbers.  In case of invalid authentication,
>   failure status is returned.
>
>         union rejected_reply switch (reject_stat stat) {
>         case RPC_MISMATCH:
>            struct {
>               unsigned int low;
>               unsigned int high;
>            } mismatch_info;
>         case AUTH_ERROR:
>            auth_stat stat;
>         };
>
> 10.  Authentication Protocols
>
>   As previously stated, authentication parameters are opaque, but
>   open-ended to the rest of the RPC protocol.  This section defines  
> two
>   standard "flavors" of authentication.  Implementors are free to
>   invent new authentication types, with the same rules of flavor  
> number
>   assignment as there is for program number assignment.  The "flavor"
>   of a credential or verifier refers to the value of the "flavor"  
> field
>   in the opaque_auth structure. Flavor numbers, like RPC program
>   numbers, are also administered centrally, and developers may assign
>   new flavor numbers by methods described in Appendix B.  Credentials
>   and verifiers are represented as variable length opaque data (the
>   "body" field in the opaque_auth structure).
>
>   In this document, two flavors of authentication are described.  Of
>   these, Null authentication (described in the next subsection) is
>   mandatory - it MUST be available in all implementations.  System
>   authentication (AUTH_SYS) is described in Appendix A.  Implementors
>   MAY include AUTH_SYS in their implementations to support existing
>   applications.  See "Security Considerations" for information about
>   other, more secure, authentication flavors.
>
> 10.1.  Null Authentication
>
>   Often calls must be made where the client does not care about its
>   identity or the server does not care who the client is.  In this
>   case, the flavor of the RPC message's credential, verifier, and  
> reply
>   verifier is "AUTH_NONE".  Opaque data associated with "AUTH_NONE" is
>   undefined.  It is recommended that the length of the opaque data be
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt          [Page  
> 14]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
>   zero.
>
> 11.  Record Marking Standard
>
>   When RPC messages are passed on top of a byte stream transport
>   protocol (like TCP), it is necessary to delimit one message from
>   another in order to detect and possibly recover from protocol  
> errors.
>   This is called record marking (RM).  One RPC message fits into one  
> RM
>   record.
>
>   A record is composed of one or more record fragments.  A record
>   fragment is a four-byte header followed by 0 to (2**31) - 1 bytes of
>   fragment data.  The bytes encode an unsigned binary number; as with
>   XDR integers, the byte order is from highest to lowest.  The number
>   encodes two values -- a boolean which indicates whether the fragment
>   is the last fragment of the record (bit value 1 implies the fragment
>   is the last fragment) and a 31-bit unsigned binary value which is  
> the
>   length in bytes of the fragment's data.  The boolean value is the
>   highest-order bit of the header; the length is the 31 low-order  
> bits.
>   (Note that this record specification is NOT in XDR standard form!)
>
> 12.  The RPC Language
>
>   Just as there was a need to describe the XDR data-types in a formal
>   language, there is also need to describe the procedures that operate
>   on these XDR data-types in a formal language as well.  The RPC
>   Language is an extension to the XDR language, with the addition of
>   "program", "procedure", and "version" declarations.  The keywords
>   "program" and "version" are reserved in the RPC Language, and
>   implementations of XDR compilers MAY reserve these keywords even  
> when
>   provided pure XDR, non-RPC, descriptions.  The following example is
>   used to describe the essence of the language.
>
> 12.1.  An Example Service Described in the RPC Language
>
>   Here is an example of the specification of a simple ping program.
>
>      program PING_PROG {
>            /*
>             * Latest and greatest version
>             */
>            version PING_VERS_PINGBACK {
>               void
>               PINGPROC_NULL(void) = 0;
>               /*
>                * Ping the client, return the round-trip time
>                * (in microseconds). Returns -1 if the operation
>                * timed out.
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt          [Page  
> 15]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
>                */
>               int
>               PINGPROC_PINGBACK(void) = 1;
>            } = 2;
>
>            /*
>             * Original version
>             */
>            version PING_VERS_ORIG {
>               void
>               PINGPROC_NULL(void) = 0;
>            } = 1;
>         } = 1;
>
>         const PING_VERS = 2;      /* latest version */
>
>   The first version described is PING_VERS_PINGBACK with two
>   procedures, PINGPROC_NULL and PINGPROC_PINGBACK.  PINGPROC_NULL  
> takes
>   no arguments and returns no results, but it is useful for computing
>   round-trip times from the client to the server and back again.  By
>   convention, procedure 0 of any RPC protocol should have the same
>   semantics, and never require any kind of authentication.  The second
>   procedure is used for the client to have the server do a reverse  
> ping
>   operation back to the client, and it returns the amount of time (in
>   microseconds) that the operation used.  The next version,
>   PING_VERS_ORIG, is the original version of the protocol and it does
>   not contain PINGPROC_PINGBACK procedure. It is useful for
>   compatibility with old client programs, and as this program matures
>   it may be dropped from the protocol entirely.
>
> 12.2.  The RPC Language Specification
>
>   The RPC language is identical to the XDR language defined in RFC
>   4506, except for the added definition of a "program-def" described
>   below.
>
>      program-def:
>         "program" identifier "{"
>            version-def
>            version-def *
>         "}" "=" constant ";"
>
>      version-def:
>         "version" identifier "{"
>             procedure-def
>             procedure-def *
>         "}" "=" constant ";"
>
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt          [Page  
> 16]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
>      procedure-def:
>         proc-return identifier "(" proc-firstarg
>           ("," type-specifier )* ")" "=" constant ";"
>
>      proc-return: "void" | type-specifier
>
>      proc-firstarg: "void" | type-specifier
>
>
> 12.3.  Syntax Notes
>
>
>   o    The following keywords are added and cannot be used as
>        identifiers: "program" and "version";
>
>   o    A version name cannot occur more than once within the scope  
> of a
>        program definition. Nor can a version number occur more than
>        once within the scope of a program definition.
>
>   o    A procedure name cannot occur more than once within the scope  
> of
>        a version definition. Nor can a procedure number occur more  
> than
>        once within the scope of version definition.
>
>   o    Program identifiers are in the same name space as constant and
>        type identifiers.
>
>   o    Only unsigned constants can be assigned to programs, versions
>        and procedures.
>
>   o    Current RPC language compilers do not generally support more
>        than one type-specifier in procedure argument lists; the usual
>        practice is to wrap arguments into a structure.
>
>
> 13.  IANA Considerations
>
>   The assignment of RPC program numbers and authentication flavor
>   numbers has in the past been performed by Sun Microsystems, Inc
>   (Sun).  This is inappropriate for an IETF standards-track protocol,
>   as such work is done well by the Internet Assigned Numbers Authority
>   (IANA).  This document proposes the transfer of authority over RPC
>   program numbers and authentication flavor numbers described here  
> from
>   Sun Microsystems, Inc. to IANA and proposes how IANA will maintain
>   and assign RPC program numbers and authentication flavor numbers.
>   Users of RPC protocols will benefit by having an independent body
>   responsible for RPC number assignments.
>
>
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt          [Page  
> 17]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
> 13.1.  Numbering Requests to IANA
>
>   Appendix B of this document describes the information to be sent to
>   IANA to request one or more RPC numbers and the rules that apply.
>   IANA should store the request for documentary purposes, and put the
>   following information into the public registry:
>
>   o    The short description of purpose and use
>
>   o    The program number(s) assigned
>
>   o    The short identifier string(s)
>
> 13.2.  Protecting Past Assignments
>
>   Sun has made assignments in both number spaces since the original
>   deployment of RPC.  The assignments made by Sun Microsystems are
>   still valid, and will be preserved.  Sun will communicate all  
> current
>   assignments in both number spaces to IANA before final handoff of
>   number assignment is done.  At the time of submission of this draft,
>   current assignments were listed at:
>
>   http://www.nfsv4-editor.org/rpc-numbers-1831bis.txt
>
> 13.3.  RPC Number Assignment
>
>   Future IANA practice should deal with the following partitioning of
>   the 32-bit number space as listed in Section 8.3.  Detailed
>   information for the administration of the partitioned blocks in
>   Section 8.3. is given below.
>
> 13.3.1.  To be assigned by IANA
>
>   The first block will be administered by IANA, with previous
>   assignments by Sun protected.  Previous assignments were restricted
>   to the range decimal 100000-399999 (0x000186a0 to 0x00061a7f),
>   therefore IANA should begin assignments at decimal 400000.
>   Individual numbers should be grated on a first-come, first-served
>   basis, and blocks should be granted under rules related to the size
>   of the block.
>
> 13.3.2.  Defined by local administrator
>
>   The "Defined by local administrator" block is available for any  
> local
>   administrative domain to use, in a similar manner to IP address
>   ranges reserved for private use.  The expected use would be through
>   the establishment of a local domain "authority" for assigning  
> numbers
>   from this range.  This authority would establish any policies or
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt          [Page  
> 18]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
>   procedures to be used within that local domain for use or assignment
>   of RPC numbers from the range.  The local domain should be
>   sufficiently isolated that it would be unlikely that RPC  
> applications
>   developed by other local domains could communicate with the domain.
>   This could result in RPC number contention, which would cause one of
>   the applications to fail.  In the absence of a local administrator,
>   this block can be utilized in a "Private Use" manner per [RFC5226].
>
> 13.3.3.  Transient block
>
>   The "Transient" block can be used by any RPC application on a "as
>   available" basis.  This range is intended for services that can
>   communicate a dynamically selected RPC program number to clients of
>   the service.  Any mechanism can be used to communicate the number.
>   Examples include shared memory when the client and server are  
> located
>   on the same system, or a network message (either RPC or otherwise)
>   that disseminates the selected number.
>
>   The transient block is not administered.  An RPC service uses this
>   range by selecting a number in the transient range and attempting to
>   register that number with the local system's RPC bindery (see the
>   RPCBPROC_SET or PMAPPROC_SET procedures in "Binding Protocols for  
> ONC
>   RPC", [RFC1833]).  If successful, no other RPC service was using  
> that
>   number and the RPC Bindery has assigned that number to the  
> requesting
>   RPC application.  The registration is valid until the RPC Bindery
>   terminates, which normally would only happen if the system reboots
>   causing all applications, including the RPC service using the
>   transient number, to terminate.  If the transient number  
> registration
>   fails, another RPC application is using the number and the requestor
>   must select another number and try again.  To avoid conflicts, the
>   recommended method is to select a number randomly from the transient
>   range.
>
>
> 13.3.4.  Reserved block
>
>   The "Reserved" blocks are available for future use.  RPC  
> applications
>   must not use numbers in these ranges unless their use is allowed by
>   future action by the IESG.
>
> 13.3.5.  RPC Number Sub-Blocks
>
>   RPC numbers are usually assigned for specific RPC services.  Some
>   applications, however, require multiple RPC numbers for a service.
>   The most common example is an RPC service that needs to have  
> multiple
>   instances of the service active simultaneously at a specific site.
>   RPC does not have an "instance identifier" in the protocol, so  
> either
>   a mechanism must be implemented to multiplex RPC requests amongst
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt          [Page  
> 19]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
>   various instances of the service, or unique RPC numbers must be used
>   by each instance.
>
>   In these cases, the RPC protocol used with the various numbers may  
> be
>   different or the same.  The numbers may be assigned dynamically by
>   the application, or as part of a site-specific administrative
>   decision.  If possible, RPC services that dynamically assign RPC
>   numbers should use the "Transient" RPC number block defined in
>   section 2.  If not possible, RPC number sub-blocks may be requested.
>
>   Assignment of RPC Number Sub-Blocks is controlled by the size of the
>   sub-block being requested.  "Specification Required" and "IESG
>   Approval" are used as defined by [RFC5226] Section 4.1.
>
>   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
>
>   Note: sub-blocks can be any size.  The limits given above are
>   maximums and smaller size sub-blocks are allowed.
>
>   Sub-blocks sized up to 100 numbers may be assigned by IANA on a  
> First
>   Come First Served basis.  The RPC Service Description included in  
> the
>   range must include an indication of how the sub-block is managed.   
> At
>   minimum, the statement should indicate whether the sub-block is used
>   with a single RPC protocol or multiple RPC protocols, and whether  
> the
>   numbers are dynamically assigned or statically (through
>   administrative action) assigned.
>
>   Sub-blocks of up to 1000 numbers must be documented in detail.  The
>   documentation must describe the RPC protocol or protocols that are  
> to
>   be used in the range.  It must also describe how the numbers within
>   the sub-block are to be assigned or used.
>
>   Sub-blocks sized over 1000 numbers must be documented as described
>   above, and the assignment must be approved by the IESG.  It is
>   expected that this will be rare.
>
>   In order to avoid multiple requests of large blocks of numbers the
>   following rule is proposed.
>
>   Requests up to and including 100 RPC numbers are handled via the
>   First Come First Served assignment method.  This 100 number
>   threshhold applies to the total number of RPC numbers assigned to an
>   individual or entity. For example, if an individual or entity first
>   requests say 70 numbers, and then later requests 40 numbers, then  
> the
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt          [Page  
> 20]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
>   request for the 40 numbers will be assigned via the Specification
>   Required method.  As long as the total number of numbers assigned
>   does not exceed 1000, IANA is free to waive the Specification
>   Required assignment for incremental requests of less than 100
>   numbers.
>
>   If an individual or entity has under 1000 numbers and later requests
>   an additional set of numbers such that the individual or entity  
> would
>   be granted over 1000 numbers, then the additional request will
>   require IESG Approval.
>
> 13.4.  RPC Authentication Flavor Number Assignment
>
>   The second number space is the authentication mechanism identifier,
>   or "flavor", number.  This number is used to distinguish between
>   various authentication mechanisms which can be optionally used with
>   an RPC message.  An authentication identifier is used in the  
> "flavor"
>   field of the "opaque_auth" structure.
>
> 13.4.1.  Assignment Policy
>
>   Appendix B of this document describes the information to be sent to
>   IANA to request one or more RPC auth numbers and the rules that
>   apply.  IANA should store the request for documentary purposes, and
>   put the following information into the public registry:
>
>   o    The short identifier string(s)
>
>   o    The auth number(s) assigned
>
>   o    The short description of purpose and use
>
> 13.4.2.  Auth Flavors vs. Pseudo-flavors
>
>   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
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt          [Page  
> 21]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
>   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.
>
>
> 14.  Security Considerations
>
>   AUTH_SYS as described in Appendix A is known to be insecure due to
>   the lack of a verifier to permit the credential to be validated.
>   AUTH_SYS SHOULD NOT be used for services which permit clients to
>   modify data.  AUTH_SYS MUST NOT be specified as RECOMMENDED or
>   REQUIRED for any standards-track RPC service.
>
>   [RFC2203] defines a new security flavor, RPCSEC_GSS, which permits
>   GSS-API [RFC2743] mechanisms to be used for securing RPC.  All non-
>   trivial RPC programs developed in future should implement
>   RPCSEC_GSS-based security appropriately.  [RFC2623] describes how
>   this was done for a widely deployed RPC program.
>
>
> 15.  Appendix A: System Authentication
>
>   The client may wish to identify itself, for example, as it is
>   identified on a UNIX(tm) system.  The flavor of the client  
> credential
>   is "AUTH_SYS".  The opaque data constituting the credential encodes
>   the following structure:
>
>         struct authsys_parms {
>            unsigned int stamp;
>            string machinename<255>;
>            unsigned int uid;
>            unsigned int gid;
>            unsigned int gids<16>;
>         };
>
>   The "stamp" is an arbitrary ID which the caller machine may  
> generate.
>   The "machinename" is the name of the caller's machine (like
>   "krypton").  The "uid" is the caller's effective user ID.  The "gid"
>   is the caller's effective group ID.  The "gids" is a counted array  
> of
>   groups which contain the caller as a member.  The verifier
>   accompanying the credential should have "AUTH_NONE" flavor value
>   (defined above).  Note this credential is only unique within a
>   particular domain of machine names, uids, and gids.
>
>   The flavor value of the verifier received in the reply message from
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt          [Page  
> 22]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
>   the server may be "AUTH_NONE" or "AUTH_SHORT".  In the case of
>   "AUTH_SHORT", the bytes of the reply verifier's string encode an
>   opaque structure.  This new opaque structure may now be passed to  
> the
>   server instead of the original "AUTH_SYS" flavor credential.  The
>   server may keep a cache which maps shorthand opaque structures
>   (passed back by way of an "AUTH_SHORT" style reply verifier) to the
>   original credentials of the caller.  The caller can save network
>   bandwidth and server cpu cycles by using the shorthand credential.
>
>   The server may flush the shorthand opaque structure at any time.  If
>   this happens, the remote procedure call message will be rejected due
>   to an authentication error.  The reason for the failure will be
>   "AUTH_REJECTEDCRED".  At this point, the client may wish to try the
>   original "AUTH_SYS" style of credential.
>
>   It should be noted that use of this flavor of authentication does  
> not
>   guarantee any security for the users or providers of a service, in
>   itself.  The authentication provided by this scheme can be  
> considered
>   legitimate only when applications using this scheme and the network
>   can be secured externally, and privileged transport addresses are
>   used for the communicating end-points (an example of this is the use
>   of privileged TCP/UDP ports in Unix systems - note that not all
>   systems enforce privileged transport address mechanisms).
>
> 16.  Appendix B: Requesting RPC program or authentication numbers
>
>   RPC numbers which must be unique across all networks are assigned by
>   the Internet Assigned Number Authority.  To apply for a single  
> number
>   or a block of numbers, electronic mail must be sent to IANA
>   <iana@isi.edu> with the following information:
>
>   o    The type of number(s) (program number or authentication flavor
>        number) sought
>
>   o    How many numbers are sought
>
>   o    The name of person or company which will use the number
>
>   o    An "identifier string" which associates the number with a
>        service
>
>   o    Email address of the contact person for the service which will
>        be using the number.
>
>   o    A short description of the purpose and use of the number
>
>   o    If an authentication flavor number is sought, and the number
>        will be a 'pseudo-flavor' intended for use with RPCSEC_GSS and
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt          [Page  
> 23]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
>        NFS, mappings analogous to those in Section 4.2 of [RFC2623]  
> are
>        required.
>
>   Specific numbers cannot be requested.  Numbers are assigned on a
>   First Come First Served basis.
>
>   For all RPC authentication flavor numbers to used on the Internet,  
> it
>   is strongly advised that an informational or standards-track RFC be
>   published describing the authentication mechanism behaviour and
>   parameters.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt          [Page  
> 24]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
> 17.  Full Copyright Statement
>
>   Copyright (C) The IETF Trust (2008).
>
>   This document is subject to the rights, licenses and restrictions
>   contained in BCP 78, and except as set forth therein, the authors
>   retain all their rights.
>
>   This document and the information contained herein are provided on  
> an
>   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE  
> REPRESENTS
>   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST  
> AND
>   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
>   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE  
> OF
>   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
>   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>
> 18.  Intellectual property
>
>   The IETF takes no position regarding the validity or scope of any
>   Intellectual Property Rights or other rights that might be claimed  
> to
>   pertain to the implementation or use of the technology described in
>   this document or the extent to which any license under such rights
>   might or might not be available; nor does it represent that it has
>   made any independent effort to identify any such rights.   
> Information
>   on the procedures with respect to rights in RFC documents can be
>   found in BCP 78 and BCP 79.
>
>   Copies of IPR disclosures made to the IETF Secretariat and any
>   assurances of licenses to be made available, or the result of an
>   attempt made to obtain a general license or permission for the use  
> of
>   such proprietary rights by implementers or users of this
>   specification can be obtained from the IETF on-line IPR repository  
> at
>   http://www.ietf.org/ipr.
>
>   The IETF invites any interested party to bring to its attention any
>   copyrights, patents or patent applications, or other proprietary
>   rights that may cover technology that may be required to implement
>   this standard.  Please address the information to the IETF at ietf-
>   ipr@ietf.org.
>
> 19.  Acknowledgment
>
>
>   Funding for the RFC Editor function is provided by the IETF
>   Administrative Support Activity (IASA).
>
>
>
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt          [Page  
> 25]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
> 20.  Normative References
>
>
>   [RFC4506]
>   Eisler, M., "XDR: External Data Representation Standard", RFC 4506,
>   May 2006
>
>
> 21.  Informative References
>
>
>   [XRPC]
>   Birrell, A. D.  & Nelson, B. J., "Implementing Remote Procedure
>   Calls", XEROX CSL-83-7, October 1983.
>
>
>   [VMTP]
>   Cheriton, D., "VMTP: Versatile Message Transaction Protocol",
>   Preliminary Version 0.3, Stanford University, January 1987.
>
>
>   [DH]
>   Diffie & Hellman, "New Directions in Cryptography", IEEE  
> Transactions
>   on Information Theory IT-22, November 1976.
>
>
>   [RFC768]
>   Postel, J., "User Datagram Protocol", STD 6, RFC 768, USC/ 
> Information
>   Sciences Institute, August 1980.
>
>
>   [RFC793]
>   Postel, J., "Transmission Control Protocol - DARPA Internet Program
>   Protocol Specification", STD 7, RFC 793, USC/Information Sciences
>   Institute, September 1981.
>
>
>   [RFC1094]
>   Sun Microsystems, Inc., "NFS: Network File System Protocol
>   Specification", RFC 1094, March 1989.
>
>
>   [RFC1813]
>   Callaghan, B., Pawlowski, B., Staubach, P., "NFS Version 3 Protocol
>   Specification", RFC 1813, June 1995.
>
>
>   [RFC1831]
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt          [Page  
> 26]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
>   R. Srinivasan, "RPC: Remote Procedure Call Protocol Specification
>   Version 2", RFC 1831, August 1995.
>
>
>   [RFC1833]
>   R. Srinivasan, "Binding Protocols for ONC RPC Version 2", RFC 1833,
>   August 1995.
>
>
>   [RFC2119]
>   Bradner, S., "Key words for use in RFCs to Indicate Requirement
>   Levels", RFC 2119, March 1997
>
>
>   [RFC2203]
>   Eisler, M., Chiu, A., Ling, L., "RPCSEC_GSS Protocol Specification",
>   RFC 2203, September 1997
>
>
>   [RFC2623]
>   Eisler, M., "NFS Version 2 and Version 3 Security Issues and the NFS
>   Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623, June 1999.
>
>
>   [RFC2695]
>   Chiu, A., "Authentication Mechanisms for ONC RPC", RFC 2695,
>   September 1999.
>
>
>   [RFC2743]
>   Linn. J., "Generic Security Service Application Program Interface
>   Version 2, Update 1", RFC 2743, January 2000.
>
>
>   [RFC3530]
>   Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C.,
>   Eisler, M., Noveck, D., "Network File System (NFS) version 4
>   Protocol", RFC 3530, April 2003.
>
>
>   [RFC5226]
>   Narten, T. and Alvestrand, H., "Guidelines for Writing an IANA
>   Considerations Section in RFCs", RFC 5226, May 2008.
>
>
>
>
>
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt          [Page  
> 27]
>
> Internet Draft  Remote Procedure Call Protocol Version 2    October  
> 2008
>
>
> 22.  Author's Address
>
>   Address comments related to this memorandum to:
>
>        nfsv4@ietf.org
>
>   Robert Thurlow
>   Sun Microsystems, Inc.
>   500 Eldorado Boulevard, UBRM05-171
>   Broomfield, CO 80021
>
>   Phone: 877-718-3419
>   E-mail: robert.thurlow@sun.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thurlow            draft-ietf-nfsv4-rfc1831bis-10.txt          [Page  
> 28]
>

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4