idnits 2.17.1 draft-ietf-nfsv4-rpc-iana-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 460. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 466. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC1831]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 107 has weird spacing: '...fffffff defi...' == Line 108 has weird spacing: '...fffffff defi...' == Line 109 has weird spacing: '...fffffff tran...' == Line 110 has weird spacing: '...fffffff rese...' == Line 111 has weird spacing: '...fffffff rese...' == (3 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2005) is 7010 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC1831' on line 476 looks like a reference -- Missing reference section? 'RFC1833' on line 484 looks like a reference -- Missing reference section? 'RFC1057' on line 472 looks like a reference -- Missing reference section? 'RFC2203' on line 488 looks like a reference -- Missing reference section? 'RFC2623' on line 496 looks like a reference -- Missing reference section? 'RFC2695' on line 500 looks like a reference -- Missing reference section? 'RFC2434' on line 492 looks like a reference -- Missing reference section? 'RFC1831bis' on line 518 looks like a reference -- Missing reference section? 'RFC1094' on line 504 looks like a reference -- Missing reference section? 'RFC1813' on line 510 looks like a reference -- Missing reference section? 'RFC3010' on line 514 looks like a reference -- Missing reference section? 'RFC1832' on line 480 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Robert Thurlow 3 Internet Draft February 2005 4 Document: draft-ietf-nfsv4-rpc-iana-03.txt 6 RPC Numbering Authority Transfer to IANA 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Discussion and suggestions for improvement are requested. This 32 document will expire in August, 2005. Distribution of this draft is 33 unlimited. 35 Abstract 37 Network services based on RPC [RFC1831] use program numbers rather 38 than well known transport ports to permit clients to find them, and 39 use authentication flavor numbers to define the format of the 40 authentication data passed. The assignment of RPC program numbers 41 and authentication flavor numbers is still performed by Sun 42 Microsystems, Inc. This is inappropriate for an IETF standard 43 protocol, as such work is done well by the Internet Assigned Numbers 44 Authority (IANA). This document defines how IANA will maintain and 45 assign RPC program numbers and authentication flavor numbers. 47 Title RPC Numbering Authority Transfer to IANA February 2005 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Past Sun Assignment Practice . . . . . . . . . . . . . . . . 3 53 2.1. RPC Program Numbers . . . . . . . . . . . . . . . . . . . 3 54 2.1.1. RPC Program Number Assignments . . . . . . . . . . . . . 3 55 2.1.2. RPC Program Protocol Definitions . . . . . . . . . . . . 4 56 2.1.3. RPC Program Numbers Actually Assigned . . . . . . . . . 4 57 2.2. RPC Authentication Flavor Numbers . . . . . . . . . . . . 4 58 3. Proposed IANA Assignment Practice . . . . . . . . . . . . . 4 59 3.1. Protecting Past Assignments . . . . . . . . . . . . . . . 4 60 3.2. RPC Number Assignment . . . . . . . . . . . . . . . . . . 5 61 3.2.1. To be assigned by IANA . . . . . . . . . . . . . . . . . 5 62 3.2.2. Defined by local administrator . . . . . . . . . . . . . 5 63 3.2.3. Transient block . . . . . . . . . . . . . . . . . . . . 6 64 3.2.4. Reserved block . . . . . . . . . . . . . . . . . . . . . 6 65 3.2.5. RPC Number Sub-Blocks . . . . . . . . . . . . . . . . . 6 66 3.2.6. Information Necessary To Grant RPC Program Numbers . . . 8 67 3.3. RPC Authentication Flavor Number Assignment . . . . . . . 9 68 3.3.1. Information Necessary To Grant RPC Authentication Flavor 69 Numbers . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4. Security Considerations . . . . . . . . . . . . . . . . . 10 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . 10 72 6. Full Copyright Statement . . . . . . . . . . . . . . . . . 10 73 7. Intellectual property . . . . . . . . . . . . . . . . . . 10 74 8. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 11 75 9. Author's Address . . . . . . . . . . . . . . . . . . . . . 13 77 Title RPC Numbering Authority Transfer to IANA February 2005 79 1. Introduction 81 This procedure will explain how RPC number assignments have been made 82 in the past and how they should be made in the future in order to 83 transfer the authority for assigning RPC program and authentication 84 flavor numbers from Sun Microsystems to IANA (the Internet Assigned 85 Number Authority). Users of RPC protocols will benefit by having an 86 independent body responsible for RPC number assignments. 88 2. Past Sun Assignment Practice 90 The administrator for these numbers was previously Sun Microsystems, 91 Inc. Requests for number assignments were sent to "rpc@sun.com" as 92 described in [RFC1831]. This section details the rules Sun used to 93 grant numbers. 95 2.1. RPC Program Numbers 97 Each application that uses RPC will typically require at least one 98 RPC program number. Because of this, there are hundreds of program 99 numbers assigned, some in delegated "blocks". 101 2.1.1. RPC Program Number Assignments 103 The program number is a 32-bit field partitioned into several blocks, 104 as defined by [RFC1831] paragraph 7.3. The table from the RFC is 105 shown in hexadecimal: 107 0 - 0x1fffffff defined by rpc@sun.com 108 0x20000000 - 0x3fffffff defined by user 109 0x40000000 - 0x5fffffff transient 110 0x60000000 - 0x7fffffff reserved 111 0x80000000 - 0x9fffffff reserved 112 0xa0000000 - 0xbfffffff reserved 113 0xc0000000 - 0xdfffffff reserved 114 0xe0000000 - 0xffffffff reserved 116 The "defined by user" block was not managed by Sun, but was intended 117 for controlled use by local administrative domains in a manner 118 similar to the "Defined by local administrator" block proposed in 119 Section 3.2.2. The "transient" block was intended to be used 120 dynamically by applications which prearranged a particular program 121 number and used it only while the application was in use. This is 122 similar to the "Transient" block proposed in Section 3.2.3. 124 Title RPC Numbering Authority Transfer to IANA February 2005 126 2.1.2. RPC Program Protocol Definitions 128 Sun Microsystems, Inc.'s former policy was to ask for RPC protocol 129 definitions in XDR definition language [RFC1833]. This information 130 was not useful, and was in some cases proprietary. Sun will not 131 transfer such definitions to IANA; the choice to publish such 132 protocols is left to the owner of the protocol. 134 2.1.3. RPC Program Numbers Actually Assigned 136 Prior to the assumption of RPC program number assignment 137 responsibilities by IANA, Sun Microsystems, Inc. assigned individual 138 and small groups of RPC numbers only within the range of 100000 to 139 399999, decimal. A small number of large blocks was also granted. 140 In hexadecimal format, these assigned blocks are: 142 0x20010000 - 0x2001ffff 143 0x20020000 - 0x2002ffff 144 0x20020000 - 0x20020007 145 0x20030000 - 0x2003ffff 146 0x20040000 - 0x2004ffff 147 0x7f000000 - 0x7fffffff 149 2.2. RPC Authentication Flavor Numbers 151 In contrast to the case with RPC program numbers, RPC authentication 152 flavor numbers are assigned only when a new authentication method is 153 developed, which is rare. Standards which define or discuss 154 authentication flavors include [RFC1057], [RFC1831], [RFC2203], 155 [RFC2623] and [RFC2695]. Since less than 20 authentication flavor 156 numbers plus two number blocks have been granted, it has not been 157 necessary to formally subdivide the 32-bit range. Individual 158 assignments are within the decimal range 0-300002. One of the 159 granted blocks is held by a group within Sun Microsystems, Inc. to 160 allocate 'pseudo-flavors' for use with RPCSEC_GSS; this decimal range 161 390000-390255 will be relinquished to IANA for further assignments 162 for the same purpose. 164 3. Proposed IANA Assignment Practice 166 3.1. Protecting Past Assignments 168 Sun has made assignments in both number spaces since the original 169 deployment of RPC. The assignments made by Sun Microsystems are 170 still valid, and existing holders of number assignments from this 171 range do not need to reapply for numbers. The conventions and 172 procedures for future assignments must account for the protection of 174 Title RPC Numbering Authority Transfer to IANA February 2005 176 these numbers. Sun will communicate all current assignments in both 177 number spaces to IANA before final handoff of number assignment is 178 done. 180 3.2. RPC Number Assignment 182 Future IANA practice should deal with the following partitioning of 183 the 32-bit number space: 185 0 Reserved 186 1 - 0x1fffffff To be assigned by IANA 187 0x20000000 - 0x3fffffff Defined by local administrator 188 (see note1) 189 0x40000000 - 0x5fffffff Transient 190 0x60000000 - 0x7effffff Reserved 191 0x7f000000 - 0x7fffffff Assignment outstanding 192 0x80000000 - 0xffffffff Reserved 194 Detailed information for the administration of these blocks is given 195 below. 197 3.2.1. To be assigned by IANA 199 The first block will be administered by IANA, with previous 200 assignments by Sun protected. Previous assignments were restricted 201 to the range decimal 100000-399999 (0x000186a0 to 0x00061a7f), 202 therefore IANA should begin assignments at decimal 400000. 203 Individual numbers should be grated on a first-come, first-served 204 basis, and blocks should be granted under rules related to the size 205 of the block. 207 3.2.2. Defined by local administrator 209 The "Defined by local administrator" block is available for any local 210 administrative domain to use, in a similar manner to IP address 211 ranges reserved for private use. The expected use would be through 212 the establishment of a local domain "authority" for assigning numbers 213 from this range. This authority would establish any policies or 214 procedures to be used within that local domain for use or assignment 215 of RPC numbers from the range. The local domain should be 216 sufficiently isolated that it would be unlikely that RPC applications 217 developed by other local domains could communicate with the domain. 218 This could result in RPC number contention, which would cause one of 219 the applications to fail. In the absence of a local administrator, 220 this block can be utilized in a "Private Use" manner per [RFC2434]. 222 Note1: Sun delegated a small number of large RPC blocks in this 223 range; see Section 2.1.3. 225 Title RPC Numbering Authority Transfer to IANA February 2005 227 3.2.3. Transient block 229 The "Transient" block can be used by any RPC application on a "as 230 available" basis. This range is intended for services that can 231 communicate a dynamically selected RPC program number to clients of 232 the service. Any mechanism can be used to communicate the number. 233 Examples include shared memory when the client and server are located 234 on the same system, or a network message (either RPC or otherwise) 235 that disseminates the selected number. 237 The transient block is not administered. An RPC service uses this 238 range by selecting a number in the transient range and attempting to 239 register that number with the local system's RPC bindery (see the 240 RPCBPROC_SET or PMAPPROC_SET procedures in "Binding Protocols for ONC 241 RPC", [RFC1833]). If successful, no other RPC service was using that 242 number and the RPC Bindery has assigned that number to the requesting 243 RPC application. The registration is valid until the RPC Bindery 244 terminates, which normally would only happen if the system reboots 245 causing all applications, including the RPC service using the 246 transient number, to terminate. If the transient number registration 247 fails, another RPC application is using the number and the requestor 248 must select another number and try again. To avoid conflicts, the 249 recommended method is to select a number randomly from the transient 250 range. 252 3.2.4. Reserved block 254 The "Reserved" blocks are available for future use. RPC applications 255 must not use numbers in these ranges unless their use is allowed by 256 future action by the IESG. 258 3.2.5. RPC Number Sub-Blocks 260 RPC numbers are usually assigned for specific RPC services. Some 261 applications, however, require multiple RPC numbers for a service. 262 The most common example is an RPC service that needs to have multiple 263 instances of the service active simultaneously at a specific site. 264 RPC does not have an "instance identifier" in the protocol, so either 265 a mechanism must be implemented to multiplex RPC requests amongst 266 various instances of the service, or unique RPC numbers must be used 267 by each instance. 269 In these cases, the RPC protocol used with the various numbers may be 270 different or the same. The numbers may be assigned dynamically by 271 the application, or as part of a site-specific administrative 272 decision. If possible, RPC services that dynamically assign RPC 273 numbers should use the "Transient" RPC number block defined in 275 Title RPC Numbering Authority Transfer to IANA February 2005 277 section 2. If not possible, RPC number sub-blocks may be requested. 279 Assignment of RPC Number Sub-Blocks is controlled by the size of the 280 sub-block being requested. "Specification Required" and "IESG 281 Approval" are used as defined by [RFC2434] Section 2. 283 Size of sub-block Assignment Method Authority 284 ----------------- ----------------- --------- 285 Up to 100 numbers First Come First Served IANA 286 Up to 1000 numbers Specification Required IANA 287 More than 1000 numbers IESG Approval required IESG 289 Note: sub-blocks can be any size. The limits given above are 290 maximums and smaller size sub-blocks are allowed. 292 Sub-blocks sized up to 100 numbers may be assigned by IANA on a First 293 Come First Served basis. The RPC Service Description included in the 294 range must include an indication of how the sub-block is managed. At 295 minimum, the statement should indicate whether the sub-block is used 296 with a single RPC protocol or multiple RPC protocols, and whether the 297 numbers are dynamically assigned or statically (through 298 administrative action) assigned. 300 Sub-blocks of up to 1000 numbers must be documented in detail. The 301 documentation must describe the RPC protocol or protocols that are to 302 be used in the range. It must also describe how the numbers within 303 the sub-block are to be assigned or used. 305 Sub-blocks sized over 1000 numbers must be documented as described 306 above, however an Internet Draft must be submitted as an 307 Informational or Standards Track RFC. If accepted as either, IANA 308 will assign the requested number sub-block. 310 In order to avoid multiple requests of large blocks of numbers the 311 following rule is proposed. 313 Requests up to and including 100 RPC numbers are handled via the 314 First Come First Served assignment method. This 100 number 315 threshhold applies to the total number of RPC numbers assigned to an 316 individual or entity. For example, if an individual or entity first 317 requests say 70 numbers, and then later requests 40 numbers, then the 318 request for the 40 numbers will be assigned via the Specification 319 Required method. As long as the total number of numbers assigned 320 does not exceed 1000, IANA is free to waive the Specification 321 Required assignment for incremental requests of less than 100 322 numbers. 324 If an individual or entity has under 1000 numbers and later requests 326 Title RPC Numbering Authority Transfer to IANA February 2005 328 an additional set of numbers such that the individual or entity would 329 over 1000 numbers, then the individual or entity will have the 330 additional request submitted to the IESG. IESG is free to waive the 331 IESG Action Required assignment method for incremental requests of 332 less than 1000 numbers. 334 3.2.6. Information Necessary To Grant RPC Program Numbers 336 [RFC1831bis] describes how users request new RPC program numbers. If 337 changes are made to that procedure, IANA should continue to request 338 the following information: 340 o Name of person or company which will use the number 342 o An "identifier string" which associates the number with a 343 service 345 o Email address of the contact person for the RPC service which 346 will be using the number. 348 o A short description of the purpose of the RPC service 350 This information is needed to associate the RPC number with an RPC 351 service, and in turn to associate an RPC service with the company or 352 person who originated the RPC service. This information may be 353 necessary for network administrators to manage their networks or 354 firewalls. Network administrators who observe RPC transactions on 355 their network may need to contact the company or person who created 356 or deployed the service to understand the application's behavior. 357 This may happen if the service is thought to be operating improperly, 358 or if its operation is having an impact on the local network. 360 In most cases, interested parties only need to know the name of the 361 RPC service using the number. IANA will make this list available 362 through publication or other means to allow for lookup of RPC 363 services by RPC number. To be effective, this requires that the 364 "identifier string" be meaningful. The string should clearly 365 identify the RPC service or application with which the RPC number is 366 to be associated. Sites supporting RPC services typically publish a 367 mapping of RPC numbers to RPC identifiers. For example, UNIX systems 368 publish this mapping in the file "/etc/rpc". 370 Title RPC Numbering Authority Transfer to IANA February 2005 372 3.3. RPC Authentication Flavor Number Assignment 374 The second number space is the authentication mechanism identifier, 375 or "flavor", number. This number is used to distinguish between 376 various authentication mechanisms which can be optionally used with 377 an RPC message. An authentication identifier is used in the "flavor" 378 field of the "opaque_auth" structure. 380 Recent progress in RPC security has focused on using the existing 381 RPCSEC_GSS flavor and inventing novel GSS-API mechanisms which can be 382 used with it. Even though RPCSEC_GSS is an assigned authentication 383 flavor, use of a new RPCSEC_GSS mechanism with NFS ([RFC1094] 384 [RFC1813] and [RFC3010]) will require the registration of 'pseudo- 385 flavors' which are used to negotiate security mechanisms in an 386 unambiguous way, as defined by [RFC2623]. Existing pseudo-flavors 387 have been granted in the decimal range 390000-390255 as described in 388 2.2. 390 For non-pseudo-flavor requests, IANA should begin granting RPC 391 authentication flavor numbers at 400000 to avoid conflicts with 392 currently granted numbers. 394 3.3.1. Information Necessary To Grant RPC Authentication Flavor Numbers 396 [RFC1831bis] describes how users request new RPC Authentication 397 Flavor numbers. If changes are made to that procedure, IANA should 398 continue to request the following information: 400 o Name of person or company which will use the number 402 o An "identifier string" which associates the number with a 403 service 405 o Email address of the contact person for the RPC service which 406 will be using the number. 408 o A description of the authentication flavor. 410 o If the authentication flavor is a 'pseudo-flavor' intended for 411 use with RPCSEC_GSS and NFS, mappings analogous to those in 412 Section 4.2 of [RFC2623] are required. 414 For authentication flavors to be used on the Internet, it is strongly 415 advised that an informational or standards-track RFC be published 416 describing the authentication mechanism behaviour and parameters. 418 Title RPC Numbering Authority Transfer to IANA February 2005 420 4. Security Considerations 422 This document has no impact on RPC security; please see [RFC1831bis] 423 and [RFC2623] for information about ROC security. 425 5. IANA Considerations 427 This entire document discusses a transition of a numbering service to 428 IANA, so this section needs nothing further. 430 6. Full Copyright Statement 432 Copyright (C) The Internet Society (2005). This document is subject 433 to the rights, licenses and restrictions contained in BCP 78, and 434 except as set forth therein, the authors retain all their rights. 436 This document and the information contained herein are provided on an 437 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 438 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 439 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 440 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 441 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 442 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 444 7. Intellectual property 446 The IETF takes no position regarding the validity or scope of any 447 Intellectual Property Rights or other rights that might be claimed to 448 pertain to the implementation or use of the technology described in 449 this document or the extent to which any license under such rights 450 might or might not be available; nor does it represent that it has 451 made any independent effort to identify any such rights. Information 452 on the procedures with respect to rights in RFC documents can be 453 found in BCP 78 and BCP 79. 455 Copies of IPR disclosures made to the IETF Secretariat and any 456 assurances of licenses to be made available, or the result of an 457 attempt made to obtain a general license or permission for the use of 458 such proprietary rights by implementers or users of this 459 specification can be obtained from the IETF on-line IPR repository at 460 http://www.ietf.org/ipr. 462 The IETF invites any interested party to bring to its attention any 463 copyrights, patents or patent applications, or other proprietary 464 rights that may cover technology that may be required to implement 465 this standard. Please address the information to the IETF at ietf- 466 ipr@ietf.org. 468 Title RPC Numbering Authority Transfer to IANA February 2005 470 8. Bibliography 472 [RFC1057] 473 Sun Microsystems Inc., "RPC: Remote Procedure Call Protocol 474 Specification Version 2", RFC 1057, August 1995. 476 [RFC1831] 477 R. Srinivasan, "RPC: Remote Procedure Call Protocol Specification 478 Version 2", RFC 1831, August 1995. 480 [RFC1832] 481 R. Srinivasan, "XDR: External Data Representation Standard", RFC 482 1832, August 1995. 484 [RFC1833] 485 R. Srinivasan, "Binding Protocols for ONC RPC Version 2", RFC 1833, 486 August 1995. 488 [RFC2203] 489 M. Eisler, A. Chiu, L. Ling, "RPCSEC_GSS Protocol Specification", RFC 490 2203, September 1997. 492 [RFC2434] 493 T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 494 Considerations Section in RFCs", RFC 2434, October 1998. 496 [RFC2623] 497 M. Eisler, "NFS Version 2 and Version 3 Security Issues and the NFS 498 Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623, June 1999. 500 [RFC2695] 501 A. Chiu, "Authentication Mechanisms for ONC RPC", RFC 2695, September 502 1999. 504 [RFC1094] 505 Sun Microsystems, Inc., "NFS: Network File System Protocol 506 Specification", RFC 1094, March 1989. 508 Title RPC Numbering Authority Transfer to IANA February 2005 510 [RFC1813] 511 B. Callaghan, B. Pawlowski. P. Staubach, "NFS Version 3 Protocol 512 Specification", RFC 1813, June 1995. 514 [RFC3010] 515 S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. 516 Eisler, D. Noveck, "NFS version 4 Protocol", RFC 3010, December 2000. 518 [RFC1831bis] 519 R. Thurlow, "RPC: Remote Procedure Call Protocol Specification 520 Version 2", draft-ietf-nfsv4-rfc1831bis-05.txt, February 2005. 522 Title RPC Numbering Authority Transfer to IANA February 2005 524 9. Author's Address 526 Address comments related to this memorandum to: 528 nfsv4-wg@sunroof.eng.sun.com 530 Robert Thurlow 531 Sun Microsystems, Inc. 532 500 Eldorado Boulevard, UBRM05-171 533 Broomfield, CO 80021 535 Phone: 877-718-3419 536 E-mail: robert.thurlow@sun.com