Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFs   Ti+SearchTech-invite World Map Symbol

RFC 7530


Network File System (NFS) Version 4 Protocol

Part 14 of 14, p. 306 to 323
Prev RFC Part


prevText      Top      Up      ToC       Page 306 
17.  NFSv4 Callback Procedures

   The procedures used for callbacks are defined in the following
   sections.  In the interest of clarity, the terms "client" and
   "server" refer to NFS clients and servers, despite the fact that for
   an individual callback RPC, the sense of these terms would be
   precisely the opposite.

17.1.  Procedure 0: CB_NULL - No Operation

17.1.1.  SYNOPSIS


17.1.2.  ARGUMENT


17.1.3.  RESULT



   Standard NULL procedure.  Void argument, void response.  Even though
   there is no direct functionality associated with this procedure, the
   server will use CB_NULL to confirm the existence of a path for RPCs
   from server to client.

Top      Up      ToC       Page 307 
17.2.  Procedure 1: CB_COMPOUND - COMPOUND Operations

17.2.1.  SYNOPSIS

     compoundargs -> compoundres

17.2.2.  ARGUMENT

   enum nfs_cb_opnum4 {
           OP_CB_GETATTR           = 3,
           OP_CB_RECALL            = 4,
           OP_CB_ILLEGAL           = 10044

   union nfs_cb_argop4 switch (unsigned argop) {
    case OP_CB_GETATTR:
         CB_GETATTR4args           opcbgetattr;
    case OP_CB_RECALL:
         CB_RECALL4args            opcbrecall;
    case OP_CB_ILLEGAL:            void;

   struct CB_COMPOUND4args {
           utf8str_cs      tag;
           uint32_t        minorversion;
           uint32_t        callback_ident;
           nfs_cb_argop4   argarray<>;

17.2.3.  RESULT

   union nfs_cb_resop4 switch (unsigned resop) {
    case OP_CB_GETATTR:    CB_GETATTR4res  opcbgetattr;
    case OP_CB_RECALL:     CB_RECALL4res   opcbrecall;
    case OP_CB_ILLEGAL:    CB_ILLEGAL4res  opcbillegal;

   struct CB_COMPOUND4res {
           nfsstat4        status;
           utf8str_cs      tag;
           nfs_cb_resop4   resarray<>;

Top      Up      ToC       Page 308 

   The CB_COMPOUND procedure is used to combine one or more of the
   callback procedures into a single RPC request.  The main callback RPC
   program has two main procedures: CB_NULL and CB_COMPOUND.  All other
   operations use the CB_COMPOUND procedure as a wrapper.

   In the processing of the CB_COMPOUND procedure, the client may find
   that it does not have the available resources to execute any or all
   of the operations within the CB_COMPOUND sequence.  In this case, the
   error NFS4ERR_RESOURCE will be returned for the particular operation
   within the CB_COMPOUND procedure where the resource exhaustion
   occurred.  This assumes that all previous operations within the
   CB_COMPOUND sequence have been evaluated successfully.

   Contained within the CB_COMPOUND results is a status field.  This
   status must be equivalent to the status of the last operation that
   was executed within the CB_COMPOUND procedure.  Therefore, if an
   operation incurred an error, then the status value will be the same
   error value as is being returned for the operation that failed.

   For the definition of the tag field, see Section 15.2.

   The value of callback_ident is supplied by the client during
   SETCLIENTID.  The server must use the client-supplied callback_ident
   during the CB_COMPOUND to allow the client to properly identify the

   Illegal operation codes are handled in the same way as they are
   handled for the COMPOUND procedure.


   The CB_COMPOUND procedure is used to combine individual operations
   into a single RPC request.  The client interprets each of the
   operations in turn.  If an operation is executed by the client and
   the status of that operation is NFS4_OK, then the next operation in
   the CB_COMPOUND procedure is executed.  The client continues this
   process until there are no more operations to be executed or one of
   the operations has a status value other than NFS4_OK.

Top      Up      ToC       Page 309 
18.  NFSv4 Callback Operations

18.1.  Operation 3: CB_GETATTR - Get Attributes

18.1.1.  SYNOPSIS

     fh, attr_request -> attrmask, attr_vals

18.1.2.  ARGUMENT

   struct CB_GETATTR4args {
           nfs_fh4 fh;
           bitmap4 attr_request;

18.1.3.  RESULT

   struct CB_GETATTR4resok {
           fattr4  obj_attributes;

   union CB_GETATTR4res switch (nfsstat4 status) {
    case NFS4_OK:
            CB_GETATTR4resok       resok4;


   The CB_GETATTR operation is used by the server to obtain the current
   modified state of a file that has been OPEN_DELEGATE_WRITE delegated.
   The size attribute and the change attribute are the only ones
   guaranteed to be serviced by the client.  See Section 10.4.3 for a
   full description of how the client and server are to interact with
   the use of CB_GETATTR.

   If the filehandle specified is not one for which the client holds an
   OPEN_DELEGATE_WRITE delegation, an NFS4ERR_BADHANDLE error is


   The client returns attrmask bits and the associated attribute values
   only for the change attribute, and attributes that it may change
   (time_modify and size).

Top      Up      ToC       Page 310 
18.2.  Operation 4: CB_RECALL - Recall an Open Delegation

18.2.1.  SYNOPSIS

     stateid, truncate, fh -> ()

18.2.2.  ARGUMENT

   struct CB_RECALL4args {
           stateid4        stateid;
           bool            truncate;
           nfs_fh4         fh;

18.2.3.  RESULT

   struct CB_RECALL4res {
           nfsstat4        status;


   The CB_RECALL operation is used to begin the process of recalling an
   open delegation and returning it to the server.

   The truncate flag is used to optimize a recall for a file that is
   about to be truncated to zero.  When it is set, the client is freed
   of obligation to propagate modified data for the file to the server,
   since this data is irrelevant.

   If the handle specified is not one for which the client holds an open
   delegation, an NFS4ERR_BADHANDLE error is returned.

   If the stateid specified is not one corresponding to an open
   delegation for the file specified by the filehandle, an
   NFS4ERR_BAD_STATEID is returned.


   The client should reply to the callback immediately.  Replying does
   not complete the recall, except when an error was returned.  The
   recall is not complete until the delegation is returned using a

Top      Up      ToC       Page 311 
18.3.  Operation 10044: CB_ILLEGAL - Illegal Callback Operation

18.3.1.  SYNOPSIS

     <null> -> ()

18.3.2.  ARGUMENT


18.3.3.  RESULT

    * CB_ILLEGAL: Response for illegal operation numbers
   struct CB_ILLEGAL4res {
           nfsstat4        status;


   This operation is a placeholder for encoding a result to handle the
   case of the client sending an operation code within COMPOUND that is
   not supported.  See Section 15.2.4 for more details.

   The status field of CB_ILLEGAL4res MUST be set to NFS4ERR_OP_ILLEGAL.


   A server will probably not send an operation with code OP_CB_ILLEGAL,
   but if it does, the response will be CB_ILLEGAL4res, just as it would
   be with any other invalid operation code.  Note that if the client
   gets an illegal operation code that is not OP_ILLEGAL, and if the
   client checks for legal operation codes during the XDR decode phase,
   then the CB_ILLEGAL4res would not be returned.

Top      Up      ToC       Page 312 
19.  Security Considerations

   NFS has historically used a model where, from an authentication
   perspective, the client was the entire machine, or at least the
   source IP address of the machine.  The NFS server relied on the NFS
   client to make the proper authentication of the end-user.  The NFS
   server in turn shared its files only to specific clients, as
   identified by the client's source IP address.  Given this model, the
   AUTH_SYS RPC security flavor simply identified the end-user using the
   client to the NFS server.  When processing NFS responses, the client
   ensured that the responses came from the same IP address and port
   number that the request was sent to.  While such a model is easy to
   implement and simple to deploy and use, it is certainly not a safe
   model.  Thus, NFSv4 mandates that implementations support a security
   model that uses end-to-end authentication, where an end-user on a
   client mutually authenticates (via cryptographic schemes that do not
   expose passwords or keys in the clear on the network) to a principal
   on an NFS server.  Consideration should also be given to the
   integrity and privacy of NFS requests and responses.  The issues of
   end-to-end mutual authentication, integrity, and privacy are
   discussed as part of Section 3.

   When an NFSv4 mandated security model is used and a security
   principal or an NFSv4 name in user@dns_domain form needs to be
   translated to or from a local representation as described in
   Section 5.9, the translation SHOULD be done in a secure manner that
   preserves the integrity of the translation.  For communication with a
   name service such as the Lightweight Directory Access Protocol (LDAP)
   ([RFC4511]), this means employing a security service that uses
   authentication and data integrity.  Kerberos and Transport Layer
   Security (TLS) ([RFC5246]) are examples of such a security service.

   Note that being REQUIRED to implement does not mean REQUIRED to use;
   AUTH_SYS can be used by NFSv4 clients and servers.  However, AUTH_SYS
   is merely an OPTIONAL security flavor in NFSv4, and so
   interoperability via AUTH_SYS is not assured.

   For reasons of reduced administration overhead, better performance,
   and/or reduction of CPU utilization, users of NFSv4 implementations
   may choose to not use security mechanisms that enable integrity
   protection on each remote procedure call and response.  The use of
   mechanisms without integrity leaves the customer vulnerable to an
   attacker in between the NFS client and server that modifies the RPC
   request and/or the response.  While implementations are free to
   provide the option to use weaker security mechanisms, there are two
   operations in particular that warrant the implementation overriding
   user choices.

Top      Up      ToC       Page 313 
   The first such operation is SECINFO.  It is recommended that the
   client issue the SECINFO call such that it is protected with a
   security flavor that has integrity protection, such as RPCSEC_GSS
   with a security triple that uses either rpc_gss_svc_integrity or
   rpc_gss_svc_privacy (rpc_gss_svc_privacy includes integrity
   protection) service.  Without integrity protection encapsulating
   SECINFO and therefore its results, an attacker in the middle could
   modify results such that the client might select a weaker algorithm
   in the set allowed by the server, making the client and/or server
   vulnerable to further attacks.

   The second operation that SHOULD use integrity protection is any
   GETATTR for the fs_locations attribute.  The attack has two steps.
   First, the attacker modifies the unprotected results of some
   operation to return NFS4ERR_MOVED.  Second, when the client follows
   up with a GETATTR for the fs_locations attribute, the attacker
   modifies the results to cause the client to migrate its traffic to a
   server controlled by the attacker.

   Because the operations SETCLIENTID/SETCLIENTID_CONFIRM are
   responsible for the release of client state, it is imperative that
   the principal used for these operations is checked against and
   matches with the previous use of these operations.  See Section 9.1.1
   for further discussion.

   Unicode in the form of UTF-8 is used for file component names (i.e.,
   both directory and file components), as well as the owner and
   owner_group attributes; other character sets may also be allowed for
   file component names.  String processing (e.g., Unicode
   normalization) raises security concerns for string comparison.  See
   Sections 5.9 and 12 for further discussion, and see [RFC6943] for
   related identifier comparison security considerations.  File
   component names are identifiers with respect to the identifier
   comparison discussion in [RFC6943] because they are used to identify
   the objects to which ACLs are applied; see Section 6.

Top      Up      ToC       Page 314 
20.  IANA Considerations

   This section uses terms that are defined in [RFC5226].

20.1.  Named Attribute Definitions

   IANA has created a registry called the "NFSv4 Named Attribute
   Definitions Registry" for [RFC3530] and [RFC5661].  This section
   introduces no new changes, but it does recap the intent.

   The NFSv4 protocol supports the association of a file with zero or
   more named attributes.  The namespace identifiers for these
   attributes are defined as string names.  The protocol does not define
   the specific assignment of the namespace for these file attributes.
   The IANA registry promotes interoperability where common interests
   exist.  While application developers are allowed to define and use
   attributes as needed, they are encouraged to register the attributes
   with IANA.

   Such registered named attributes are presumed to apply to all minor
   versions of NFSv4, including those defined subsequently to the
   registration.  Where the named attribute is intended to be limited
   with regard to the minor versions for which they are not to be used,
   the assignment in the registry will clearly state the applicable

   The registry is to be maintained using the Specification Required
   policy as defined in Section 4.1 of [RFC5226].

   Under the NFSv4 specification, the name of a named attribute can in
   theory be up to 2^32 - 1 bytes in length, but in practice NFSv4
   clients and servers will be unable to handle a string that long.
   IANA should reject any assignment request with a named attribute that
   exceeds 128 UTF-8 characters.  To give the IESG the flexibility to
   set up bases of assignment of Experimental Use and Standards Action,
   the prefixes of "EXPE" and "STDS" are Reserved.  The zero-length
   named attribute name is Reserved.

   The prefix "PRIV" is allocated for Private Use.  A site that wants to
   make use of unregistered named attributes without risk of conflicting
   with an assignment in IANA's registry should use the prefix "PRIV" in
   all of its named attributes.

Top      Up      ToC       Page 315 
   Because some NFSv4 clients and servers have case-insensitive
   semantics, the fifteen additional lowercase and mixed-case
   permutations of each of "EXPE", "PRIV", and "STDS" are Reserved
   (e.g., "expe", "expE", "exPe", etc. are Reserved).  Similarly, IANA
   must not allow two assignments that would conflict if both named
   attributes were converted to a common case.

   The registry of named attributes is a list of assignments, each
   containing three fields for each assignment.

   1.  A US-ASCII string name that is the actual name of the attribute.
       This name must be unique.  This string name can be 1 to 128 UTF-8
       characters long.

   2.  A reference to the specification of the named attribute.  The
       reference can consume up to 256 bytes (or more, if IANA permits).

   3.  The point of contact of the registrant.  The point of contact can
       consume up to 256 bytes (or more, if IANA permits).

20.1.1.  Initial Registry

   There is no initial registry.

20.1.2.  Updating Registrations

   The registrant is always permitted to update the point of contact
   field.  To make any other change will require Expert Review or IESG

20.2.  Updates to Existing IANA Registries

   In addition, because this document obsoletes RFC 3530, IANA has

   o  replaced all references to RFC 3530 in the Network Identifier
      (r_netid) registry with references to this document.

   o  replaced the reference to the nfs registration's reference to
      RFC 3530 in the GSSAPI/Kerberos/SASL Service names registry with a
      reference to this document.

Top      Up      ToC       Page 316 
21.  References

21.1.  Normative References

   [RFC20]    Cerf, V., "ASCII format for network interchange", STD 80,
              RFC 20, October 1969,

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,

   [RFC2203]  Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
              Specification", RFC 2203, September 1997,

   [RFC2743]  Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743, January 2000,

   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, March 2003,

   [RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode
              for Internationalized Domain Names in Applications
              (IDNA)", RFC 3492, March 2003,

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of
              ISO 10646", STD 63, RFC 3629, November 2003,

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008, <>.

   [RFC5403]  Eisler, M., "RPCSEC_GSS Version 2", RFC 5403,
              February 2009, <>.

   [RFC5531]  Thurlow, R., "RPC: Remote Procedure Call Protocol
              Specification Version 2", RFC 5531, May 2009,

Top      Up      ToC       Page 317 
   [RFC5665]  Eisler, M., "IANA Considerations for Remote Procedure Call
              (RPC) Network Identifiers and Universal Address Formats",
              RFC 5665, January 2010,

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, August 2010,

   [RFC5891]  Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891, August 2010,

   [RFC6649]  Hornquist Astrand, L. and T. Yu, "Deprecate DES,
              RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in
              Kerberos", BCP 179, RFC 6649, July 2012,

   [RFC7531]  Haynes, T., Ed., and D. Noveck, Ed., "Network File System
              (NFS) Version 4 External Data Representation Standard
              (XDR) Description", RFC 7531, March 2015,

              The Unicode Consortium, "SpecialCasing-7.0.0.txt", Unicode
              Character Database, March 2014, <

   [UNICODE]  The Unicode Consortium, "The Unicode Standard,
              Version 7.0.0", (Mountain View, CA: The Unicode
              Consortium, 2014 ISBN 978-1-936213-09-2), June 2014,

              The Open Group, "Section 3.372 of Chapter 3 of Base
              Definitions of The Open Group Base Specifications
              Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version),
              ISBN 1937218287, April 2013, <>.

Top      Up      ToC       Page 318 
21.2.  Informative References

   [Chet]     Juszczak, C., "Improving the Performance and Correctness
              of an NFS Server", USENIX Conference Proceedings,
              June 1990.

   [Floyd]    Floyd, S. and V. Jacobson, "The Synchronization of
              Periodic Routing Messages", IEEE/ACM Transactions on
              Networking 2(2), pp. 122-136, April 1994.

              IESG, "IESG Processing of RFC Errata for the IETF Stream",
              July 2008.

   [MS-SMB]   Microsoft Corporation, "Server Message Block (SMB)
              Protocol Specification", MS-SMB 43.0, May 2014.

              Institute of Electrical and Electronics Engineers, Inc.,
              "IEEE Draft P1003.1e", 1997.

   [RFC1094]  Nowicki, B., "NFS: Network File System Protocol
              specification", RFC 1094, March 1989,

   [RFC1813]  Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
              Version 3 Protocol Specification", RFC 1813, June 1995,

   [RFC1833]  Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
              RFC 1833, August 1995,

   [RFC2054]  Callaghan, B., "WebNFS Client Specification", RFC 2054,
              October 1996, <>.

   [RFC2055]  Callaghan, B., "WebNFS Server Specification", RFC 2055,
              October 1996, <>.

   [RFC2224]  Callaghan, B., "NFS URL Scheme", RFC 2224, October 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,

Top      Up      ToC       Page 319 
   [RFC2624]  Shepler, S., "NFS Version 4 Design Considerations",
              RFC 2624, June 1999,

   [RFC2755]  Chiu, A., Eisler, M., and B. Callaghan, "Security
              Negotiation for WebNFS", RFC 2755, January 2000,

   [RFC3010]  Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
              Beame, C., Eisler, M., and D. Noveck, "NFS version 4
              Protocol", RFC 3010, December 2000,

   [RFC3232]  Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced
              by an On-line Database", RFC 3232, January 2002,

   [RFC3530]  Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
              Beame, C., Eisler, M., and D. Noveck, "Network File System
              (NFS) version 4 Protocol", RFC 3530, April 2003,

   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
              Version 5 Generic Security Service Application Program
              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
              July 2005, <>.

   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
              Simple and Protected Generic Security Service Application
              Program Interface (GSS-API) Negotiation Mechanism",
              RFC 4178, October 2005,

   [RFC4506]  Eisler, M., Ed., "XDR: External Data Representation
              Standard", STD 67, RFC 4506, May 2006,

   [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
              Protocol (LDAP): The Protocol", RFC 4511, June 2006,

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008,

Top      Up      ToC       Page 320 
   [RFC5661]  Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
              "Network File System (NFS) Version 4 Minor Version 1
              Protocol", RFC 5661, January 2010,

   [RFC6365]  Hoffman, P. and J. Klensin, "Terminology Used in
              Internationalization in the IETF", BCP 166, RFC 6365,
              September 2011, <>.

   [RFC6943]  Thaler, D., Ed., "Issues in Identifier Comparison for
              Security Purposes", RFC 6943, May 2013,

   [fcntl]    The Open Group, "Section 'fcntl()' of System Interfaces of
              The Open Group Base Specifications Issue 7", IEEE
              Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287,
              April 2013, <>.

   [fsync]    The Open Group, "Section 'fsync()' of System Interfaces of
              The Open Group Base Specifications Issue 7", IEEE
              Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287,
              April 2013, <>.

              The Open Group, "Section 'getpwnam()' of System Interfaces
              of The Open Group Base Specifications Issue 7", IEEE
              Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287,
              April 2013, <>.

              The Open Group, "Section 'read()' of System Interfaces of
              The Open Group Base Specifications Issue 7", IEEE
              Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287,
              April 2013, <>.

              The Open Group, "Section 'readdir()' of System Interfaces
              of The Open Group Base Specifications Issue 7", IEEE
              Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287,
              April 2013, <>.

   [stat]     The Open Group, "Section 'stat()' of System Interfaces of
              The Open Group Base Specifications Issue 7", IEEE
              Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287,
              April 2013, <>.

Top      Up      ToC       Page 321 
   [unlink]   The Open Group, "Section 'unlink()' of System Interfaces
              of The Open Group Base Specifications Issue 7", IEEE
              Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287,
              April 2013, <>.

              The Open Group, "Section 'write()' of System Interfaces of
              The Open Group Base Specifications Issue 7", IEEE
              Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287,
              April 2013, <>.

   [xnfs]     The Open Group, "Protocols for Interworking: XNFS,
              Version 3W, ISBN 1-85912-184-5", February 1998.

Top      Up      ToC       Page 322 

   A bis is certainly built on the shoulders of the first attempt.
   Spencer Shepler, Brent Callaghan, David Robinson, Robert Thurlow,
   Carl Beame, Mike Eisler, and David Noveck are responsible for a great
   deal of the effort in this work.

   Tom Haynes would like to thank NetApp, Inc. for its funding of his
   time on this project.

   Rob Thurlow clarified how a client should contact a new server if a
   migration has occurred.

   David Black, Nico Williams, Mike Eisler, Trond Myklebust, James
   Lentini, and Mike Kupfer read many earlier draft versions of
   Section 12 and contributed numerous useful suggestions, without which
   the necessary revision of that section for this document would not
   have been possible.

   Peter Staubach read almost all of the earlier draft versions of
   Section 12, leading to the published result, and his numerous
   comments were always useful and contributed substantially to
   improving the quality of the final result.

   Peter Saint-Andre was gracious enough to read the most recent draft
   version of Section 12 and provided some key insight as to the
   concerns of the Internationalization community.

   James Lentini graciously read the rewrite of Section 8, and his
   comments were vital in improving the quality of that effort.

   Rob Thurlow, Sorin Faibish, James Lentini, Bruce Fields, and Trond
   Myklebust were faithful attendants of the biweekly triage meeting and
   accepted many an action item.

   Bruce Fields was a good sounding board for both the third edge
   condition and courtesy locks in general.  He was also the leading
   advocate of stamping out backport issues from [RFC5661].

   Marcel Telka was a champion of straightening out the difference
   between a lock-owner and an open-owner.  He has also been diligent in
   reviewing the final document.

   Benjamin Kaduk reminded us that DES is dead, and Nico Williams helped
   us close the lid on the coffin.

   Elwyn Davies provided a very thorough and engaging Gen-ART review;

Top      Up      ToC       Page 323 
Authors' Addresses

   Thomas Haynes (editor)
   Primary Data, Inc.
   4300 El Camino Real Ste 100
   Los Altos, CA  94022
   United States

   Phone: +1 408 215 1519

   David Noveck (editor)
   300 Innovative Way
   Nashua, NH  03062
   United States

   Phone: +1 781 572 8038