idnits 2.17.1 draft-ietf-nfsv4-rpc-netid-05.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 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 554. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 560. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document updates RFC1833, but the abstract doesn't seem to directly say this. It does mention RFC1833 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC1833, updated by this document, for RFC5378 checks: 1994-11-30) -- 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 (December 10, 2008) is 5613 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) -- Obsolete informational reference (is this intentional?): RFC 1831 (ref. '4') (Obsoleted by RFC 5531) -- Obsolete informational reference (is this intentional?): RFC 3530 (ref. '5') (Obsoleted by RFC 7530) -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. '7') (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '12') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '13') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '14') (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 M. Eisler 3 Internet-Draft NetApp 4 Updates: 1833 (if approved) December 10, 2008 5 Intended status: Standards Track 6 Expires: June 13, 2009 8 IANA Considerations for RPC Net Identifiers and Universal Address 9 Formats 10 draft-ietf-nfsv4-rpc-netid-05.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on June 13, 2009. 37 Abstract 39 This Internet-Draft lists IANA Considerations for RPC Network 40 Identifiers (netids) and RPC Universal Network Addresses (uaddrs). 41 This Internet-Draft updates, but does not replace, RFC1833. 43 Requirements Language 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC 2119 [1]. 49 Table of Contents 51 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 52 2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 54 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 55 4.1. IANA Considerations for Netids . . . . . . . . . . . . . . 3 56 4.1.1. Initial Registry . . . . . . . . . . . . . . . . . . . 6 57 4.1.2. Updating Registrations . . . . . . . . . . . . . . . . 7 58 4.2. IANA Considerations for Uaddr Formats . . . . . . . . . . 7 59 4.2.1. Initial Registry . . . . . . . . . . . . . . . . . . . 8 60 4.2.2. Updating Registrations . . . . . . . . . . . . . . . . 9 61 4.2.3. Uaddr Formats . . . . . . . . . . . . . . . . . . . . 9 62 4.3. Cross Referencing Between the Netid and Format Registry . 10 63 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 5.1. Normative References . . . . . . . . . . . . . . . . . . . 10 65 5.2. Informative References . . . . . . . . . . . . . . . . . . 11 66 Appendix A. RFC Editor Notes . . . . . . . . . . . . . . . . . . 12 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 Intellectual Property and Copyright Statements . . . . . . . . . . 13 70 1. Introduction and Motivation 72 The concepts of an RPC (defined in RFC1831 [4]) Network Identifier 73 (netid) and an RPC Universal Address (uaddr) were introduced in 74 RFC1833 [2] for distinguishing network addresses of multiple 75 protocols and representing those addresses in a canonical form. 76 RFC1833 states that a netid ``is defined by a system administrator 77 based on local conventions, and cannot be depended on to have the 78 same value on every system.'' (The netid is contained in the field 79 r_netid of the data type rpcb_entry, and the uaddr is contained in 80 the field r_addr of the same data type, where rpcb_entry is defined 81 in RFC1833.) Since the publication of RFC1833, it has been found 82 that protocols like NFSv4.0 [5] and RPC/RDMA [6] depend on consistent 83 values of netids and representations of uaddrs. Current practices 84 tend to ensure this consistency. Thus, this document identifies the 85 considerations for IANA to establish registries of netids and uaddr 86 formats for RPC and specifies the initial content of the two 87 registries. 89 2. Acknowledgements 91 Lars Eggert, Juergen Schoenwaelder, and Robert Sparks reviewed the 92 document and gave valuable feed back. 94 3. Security Considerations 96 Since this document is only concerned with the IANA management of the 97 Network Identifier (netid) and Universal Network Addresses (uaddrs) 98 format registry, it raises no new security issues. 100 4. IANA Considerations 102 This section uses terms that are defined in RFC5226 [7]. 104 4.1. IANA Considerations for Netids 106 IANA will create a registry called "ONC RPC Netids". The remainder 107 of this section describes the registry. 109 All assignments to the ONC RPC Netids registry are made on one of two 110 bases: 112 o A First Come First Served basis subregistry per section 4.1 of 113 RFC5226. 115 o A Standards Action basis subregistry per section 4.1 of RFC5226. 117 The XDR encoding allows netids to be up to 2^32 - 1 octets in length, 118 but the registry will only allow a much shorter length. Assignments 119 made on a Standards Action basis should be assigned netids one to 120 eight octets long. Assignments made on a First Come First Served 121 basis should be assigned netids nine to 128 octets long. Some 122 exceptions are listed in Table 2. 124 Some portion of the netid name space is Reserved: 126 o All netids, regardless of length, that start with the prefixes 127 "STDS" or "FCFS" are Reserved, in order to extend the name space 128 of either Standards Action or First Come First Served bases. 130 o To give IESG the flexibility in the future to permit Private and 131 Experimental Uses, all netids with the prefixes "PRIV" or "EXPE" 132 are Reserved. 134 o To prevent confusion with the control protocol by the same name 135 [8], netids with the prefix "ICMP" are Reserved. 137 o Since netids are not constructed in an explicit hierarchical 138 manner, this document does not provide for Hierarchical Allocation 139 of netids. Nonetheless, all netids containing the octet "." are 140 Reserved for future possible provision of Hierarchical Allocation. 142 o The zero length netid is Reserved. 144 A recommended convention for netids corresponding to transports that 145 work over the IPv6 protocol is to have "6" as the last character in 146 the netid's name. 148 There are two subregistries of netids, one for Standards Action 149 assignments, and one for First Come First Serve assignments. Each 150 registry of netids is a list of assignments, each containing five 151 fields for each assignment. 153 1. A US-ASCII string name that is the actual netid. The netid 154 should be one to eight octets long for the Standards Action 155 subregistry, and should be nine to 128 octets long for the First 156 Come First Served subregistry. The netid MUST NOT conflict with 157 any other registered netid. Despite the fact that netids are 158 case sensitive, the netid, when mapped to all upper case MUST NOT 159 conflict with the value of any other registered netid after the 160 registered netid is mapped to upper case. In addition, when 161 mapped to upper case, the prefix of the netid MUST NOT be equal 162 to a Reserved prefix. 164 2. A constant name that can be used for software programs that wish 165 to use the transport protocol associated with protocol. The name 166 of the constant typically has the prefix: "NC_", and a suffix 167 equal to the upper case version of the netid. This constant name 168 should be a constant that is valid in the 'C' programming 169 language. This constant name MUST NOT conflict with any other 170 netid constant name. Constant names with the prefix "NC_STDS", 171 "NC_FCFS", "NC_PRIV", "NC_EXPE", and "NC_ICMP" are Reserved. 172 Constant names with a prefix of "NC_" and a total length of 11 173 characters or less should be for assignments made on the 174 Standards Action basis. The constant "NC_" is Reserved. The 175 constant name can be one to 131 octets long. 177 3. A description and/or a reference to a description of the how the 178 netid will be used. For assignments made on a First Come First 179 Served basis the description should include, if applicable, a 180 reference to the transport and network protocols corresponding to 181 the netid. For assignments made on a Standards Action basis, the 182 description field must include the RFC numbers of the protocol 183 associated with the netid, including if applicable, RFC numbers 184 of the transport and network protocols. 186 4. A point of contact of the registrant. For assignments made on a 187 First Come First Served basis, 189 * the point of contact should include an email address. 191 * subject to authorization by a Designated Expert, the point of 192 contact may be omitted for extraordinary situations, such as 193 the registration of a commonly used netid where the owner is 194 unknown. 196 For assignments made on a Standards Action basis the point of 197 contact is always determined by IESG. 199 5. A numerical value, used to cross reference the netid assignment 200 with an assignment in the uaddr format registry (see 201 Section 4.2). If the registrant is registering a netid that 202 cross references an existing assignment in the uaddr format 203 registry, then the registrant provides the actual value of the 204 cross reference along with the date the registrant retrieved the 205 cross reference value from the uaddr format registry. If the 206 registrant is registering both a new netid and new uaddr format, 207 then the registrant provides a value of TBD1 in the netid 208 request, and uses TBD1 in the the uaddr format request. IANA 209 will then substitute TBD1 for cross reference number IANA 210 allocates. 212 4.1.1. Initial Registry 214 The initial list of netids is broken into two subregistries: those 215 assigned on a First Come First Serve basis in Table 1 and those 216 assigned on a Standards Action basis in Table 2. These lists will 217 change when IANA registers additional netids as needed, and the 218 authoritative list of registered netids will always live with IANA. 220 +-------------+--------------+---------------------------+-----+----+ 221 | Netid | Constant | Description and/or | PoC | CR | 222 | | Name | Reference | | | 223 +-------------+--------------+---------------------------+-----+----+ 224 | "-" | NC_NOPROTO | RFC1833 [2], | | 1 | 225 | | | Section 4.2.3.2 of | | | 226 | | | RFCTBD2 | | | 227 | "ticlts" | NC_TICLTS | The loop back | | 0 | 228 | | | connectionless transport | | | 229 | | | used in System V Release | | | 230 | | | 4 and other operating | | | 231 | | | systems. Although this | | | 232 | | | assignment is made on a | | | 233 | | | First Come First Served | | | 234 | | | basis and is fewer than | | | 235 | | | nine characters long, the | | | 236 | | | exception is authorized. | | | 237 | | | See [9]. | | | 238 | "ticots" | NC_TICOTS | The loop back | | 0 | 239 | | | connection-oriented | | | 240 | | | transport used in System | | | 241 | | | V Release 4 and other | | | 242 | | | operating systems. See | | | 243 | | | [9]. Although this | | | 244 | | | assignment is made on a | | | 245 | | | First Come First Served | | | 246 | | | basis and is fewer than | | | 247 | | | nine characters long, the | | | 248 | | | exception is authorized. | | | 249 | "ticotsord" | NC_TICOTSORD | The loop back | | 0 | 250 | | | connection-oriented with | | | 251 | | | orderly-release transport | | | 252 | | | used in System V Release | | | 253 | | | 4 and other operating | | | 254 | | | systems. See [9]. | | | 255 +-------------+--------------+---------------------------+-----+----+ 257 Table 1: Initial First Come First Serve Netid Assignments 259 PoC: Point of Contact. CR: Cross Reference to the Uaddr Format 260 Registry. 262 +---------+--------------+------------------------------+------+----+ 263 | Netid | Constant | RFC(s) and Description (if | PoC | CR | 264 | | Name | needed) | | | 265 +---------+--------------+------------------------------+------+----+ 266 | "dccp" | NC_DCCP | RFC4340 [10] RFC0791 [11] | IESG | 2 | 267 | "dccp6" | NC_DCCP6 | RFC4340 [10] RFC2460 [12] | IESG | 3 | 268 | "rdma" | NC_RDMA | RFCTBD1 [6] RFC0791 [11] | IESG | 2 | 269 | "rdma6" | NC_RDMA6 | RFCTBD1 [6] RFC2460 [12] | IESG | 3 | 270 | "sctp" | NC_SCTP | RFC2960 [13] RFC0791 [11] | IESG | 2 | 271 | "sctp6" | NC_SCTP6 | RFC2960 [13] RFC2460 [12] | IESG | 3 | 272 | "tcp" | NC_TCP | RFC0793 [14] RFC0791 [11] | IESG | 2 | 273 | "tcp6" | NC_TCP6 | RFC0793 [14] RFC2460 [12] | IESG | 3 | 274 | "udp" | NC_UDP | RFC0768 [15] RFC0791 [11] | IESG | 2 | 275 | "udp6" | NC_UDP6 | RFC0768 [15] RFC2460 [12] | IESG | 3 | 276 +---------+--------------+------------------------------+------+----+ 278 Table 2: Initial Standards Action Netid Assignments 280 4.1.2. Updating Registrations 282 Per section 5.2 of RFC5226 the registrant is always permitted to 283 update a registration made on a First Come First Served basis 284 "subject to the same constraints and review as with new 285 registrations." IESG or a Designated Expert is permitted to update 286 any registration made on a First Come First Served basis, which 287 normally is done when the PoC cannot be reached in order to make 288 necessary updates. Examples where an update would be needed include, 289 but are not limited to: the email address or other contact 290 information becomes invalid; the reference to the corresponding 291 protocol becomes obsolete or unavailable; and RFC1833 is updated or 292 replaced in such a way that the scope of netids changes, requiring 293 additional fields in the assignment. 295 Only IESG, on the advice of a Designated Expert, can update a 296 registration made on a Standards Action basis. 298 4.2. IANA Considerations for Uaddr Formats 300 IANA will create a registry called "ONC RPC Uaddr Format Registry" 301 (called the "format registry" for the remainder of this document). 302 The remainder of this section describes the registry. 304 All assignments to the format registry are made on one of two bases: 306 o First Come First Served basis per section 4.1 of RFC5226. 308 o Standards Action per section 4.1 of RFC5226. 310 The registry of formats is a list of assignments, each containing 311 four fields for each assignment. 313 1. The basis for the assignment, which can be either FCFS for First 314 Come First Served assignments, or STDS for Standards Action 315 assignments. 317 2. A description and/or reference to a description of the actual 318 uaddr format. Assignments made on a Standards Action basis 319 always have a reference to an RFC. 321 3. For assignments made on a First Come First Served basis, a point 322 of contact, including an email address. Subject to authorization 323 by a Designated Expert, the point of contact may be omitted for 324 extraordinary situations, such as the registration of a commonly 325 used format where the owner is unknown. For assignments made on 326 a Standards Action basis, the point of contact is always 327 determined by IESG. 329 4. A numerical value, used to cross reference the format assignment 330 with an assignment in the netid registry. The registrant 331 provides a value of TBD1 for the cross reference field when 332 requesting an assignment. IANA will assign TBD1 to a real value. 334 All requests for assignments to the format registry on a Standards 335 Action basis must undergo Expert Review and must be approved by IESG. 337 4.2.1. Initial Registry 339 The initial list of formats is in Table 3. This lists will change 340 when IANA registers additional formats as needed, and the 341 authoritative list of registered formats will always live with IANA. 343 +-------+-----------------------------------------------+------+----+ 344 | Basis | Description and/or Reference | PoC | CR | 345 +-------+-----------------------------------------------+------+----+ 346 | FCFS | System V Release 4 loopback transport uaddr | | 0 | 347 | | format. Section 4.2.3.1 of RFCTBD2 | | | 348 | FCFS | Uaddr format for NC_NOPROTO. Section 4.2.3.2 | | 1 | 349 | | of RFCTBD2 | | | 350 | STDS | Uaddr format for IPv4 transports. | IESG | 2 | 351 | | Section 4.2.3.3 of RFCTBD2 | | | 352 | STDS | Uaddr format for IPv6 transports. | IESG | 3 | 353 | | Section 4.2.3.4 of RFCTBD2 | | | 354 +-------+-----------------------------------------------+------+----+ 355 Table 3: Initial Format Assignments 357 4.2.2. Updating Registrations 359 The registrant is always permitted to update a registration made on a 360 First Come First Served basis "subject to the same constraints and 361 review as with new registrations." IESG is permitted to update any 362 registration made on a First Come First Served basis, which normally 363 is done when the PoC cannot be reached in order to make necessary 364 updates. Examples where an update would be needed include, but are 365 not limited to: the email address or other contact information 366 becomes invalid; the reference to the format description becomes 367 obsolete or unavailable; and RFC1833 is updated or replaced in such a 368 way that the scope of uaddr formats changes, requiring additional 369 fields in the assignment. 371 Only IESG, on the advice of a Designated Expert, can update a 372 registration made on a Standards Action basis. 374 4.2.3. Uaddr Formats 376 4.2.3.1. Uaddr Format for System V Release 4 Loopback Transports 378 Although RFC1833 specifies the uaddr as the XDR data type string 379 (hence, limited to US-ASCII), implementations of the System V Release 380 4 loopback transports will use an opaque string of octets. Thus the 381 format of a loopback transport address is any non-zero length array 382 of octets. 384 4.2.3.2. Uaddr Format for Netid "-" 386 There is no address format for netid "-". This netid is apparently 387 for internal use for supporting some implementations of RFC1833. 389 4.2.3.3. Uaddr Format for Most IPv4 Transports 391 Most transport protocols that operate over IPv4 use 16 bit port 392 numbers, including DCCP [10], RDMA [6], SCTP [13], TCP [14], and UDP 393 [15]. The format of the uaddr for the above 16 bit port transports 394 (when used over IPv4) is the US-ASCII string: 396 h1.h2.h3.h4.p1.p2 398 The prefix, "h1.h2.h3.h4", is the standard textual form for 399 representing an IPv4 address, which is always four octets long. 400 Assuming big-endian ordering, h1, h2, h3, and h4, are respectively, 401 the first through fourth octets each converted to ASCII-decimal. The 402 suffix, "p1.p2", is a textual form for representing a service port. 404 Assuming big-endian ordering, p1 and p2 are, respectively, the first 405 and second octets each converted to ASCII-decimal. For example, if a 406 host, in big-endian order, has an address in hexadecimal of 407 0xC0000207 and there is a service listening on, in big endian order, 408 port 0xCB51 (decimal 52049) then the complete uaddr is 409 "192.0.2.7.203.81". 411 4.2.3.4. Uaddr Format for Most IPv6 Transports 413 Most transport protocols that operate over IPv6 use 16 bit port 414 numbers, including DCCP [10], RDMA [6], SCTP [13], TCP [14], and UDP 415 [15]. The format of the uaddr for the above 16 bit port transports 416 (when used over IPv6) is the US-ASCII string: 418 x1:x2:x3:x4:x5:x6:x7:x8.p1.p2 420 The suffix "p1.p2" is the service port, and is computed the same way 421 as with uaddrs for transports over IPv4 (see Section 4.2.3.3). The 422 prefix, "x1:x2:x3:x4:x5:x6:x7:x8", is the preferred textual form for 423 representing an IPv6 address as defined in Section 2.2 of RFC4291 424 [3]. Additionally, the two alternative forms specified in Section 425 2.2 of RFC4291 are also acceptable. 427 4.2.3.5. Uaddr Format for ICMP over IPv4 and IPv6 429 As ICMP is not a true transport, there is no uaddr format for ICMP. 430 The netid assignments "icmp" and "icmp6" and their shared uaddr 431 "format" are listed to prevent any registrant from allocating the 432 netids "icmp" and "icmp6" for a purpose that would likely cause 433 confusion. 435 4.3. Cross Referencing Between the Netid and Format Registry 437 The last field of the netids registry is used to cross reference with 438 the last field of the format registry. IANA is under no obligation 439 to maintain same numeric value in cross references when updating each 440 registry; i.e. IANA is free to "re-number" these corresponding 441 fields. However, if IANA does so, both the netid and format 442 registries must be updated atomically. 444 5. References 446 5.1. Normative References 448 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 449 Levels", RFC 2119, March 1997. 451 [2] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", 452 RFC 1833, August 1995. 454 [3] Hinden, R. and S. Deering, "IP Version 6 Addressing 455 Architecture", RFC 4291, February 2006. 457 5.2. Informative References 459 [4] Srinivasan, R., "RPC: Remote Procedure Call Protocol 460 Specification Version 2", RFC 1831, August 1995. 462 [5] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, 463 C., Eisler, M., and D. Noveck, "Network File System (NFS) 464 version 4 Protocol", RFC 3530, April 2003. 466 [6] Talpey, T. and B. Callaghan, "Remote Direct Memory Access 467 Transport for Remote Procedure Call", 468 draft-ietf-nfsv4-rpcrdma-09 (work in progress), December 2008. 470 [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 471 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 473 [8] Postel, J., "Internet Control Message Protocol", STD 5, 474 RFC 792, September 1981. 476 [9] American Telephone and Telegraph Company, "UNIX System V, 477 Release 4 Programmer's Guide: Networking Interfaces, ISBN 478 0139470786", 1990. 480 [10] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion 481 Control Protocol (DCCP)", RFC 4340, March 2006. 483 [11] Postel, J., "Internet Protocol", STD 5, RFC 791, 484 September 1981. 486 [12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 487 Specification", RFC 2460, December 1998. 489 [13] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 490 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 491 Paxson, "Stream Control Transmission Protocol", RFC 2960, 492 October 2000. 494 [14] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 495 September 1981. 497 [15] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 498 August 1980. 500 Appendix A. RFC Editor Notes 502 [RFC Editor: please remove this section prior to publication.] 504 [RFC Editor: Please replace occurrences of RFCTBD1 with the RFCxxxx 505 where xxxx is the RFC number assigned to the document referenced in 506 [6].] 508 [RFC Editor: Please replace occurrences of RFCTBD2 with the RFCyyyy 509 where yyyy is the RFC number assigned to this document.] 511 Author's Address 513 Mike Eisler 514 NetApp 515 5765 Chase Point Circle 516 Colorado Springs, CO 80919 517 US 519 Phone: +1-719-599-9026 520 Email: mike@eisler.com 522 Full Copyright Statement 524 Copyright (C) The IETF Trust (2008). 526 This document is subject to the rights, licenses and restrictions 527 contained in BCP 78, and except as set forth therein, the authors 528 retain all their rights. 530 This document and the information contained herein are provided on an 531 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 532 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 533 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 534 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 535 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 536 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 538 Intellectual Property 540 The IETF takes no position regarding the validity or scope of any 541 Intellectual Property Rights or other rights that might be claimed to 542 pertain to the implementation or use of the technology described in 543 this document or the extent to which any license under such rights 544 might or might not be available; nor does it represent that it has 545 made any independent effort to identify any such rights. Information 546 on the procedures with respect to rights in RFC documents can be 547 found in BCP 78 and BCP 79. 549 Copies of IPR disclosures made to the IETF Secretariat and any 550 assurances of licenses to be made available, or the result of an 551 attempt made to obtain a general license or permission for the use of 552 such proprietary rights by implementers or users of this 553 specification can be obtained from the IETF on-line IPR repository at 554 http://www.ietf.org/ipr. 556 The IETF invites any interested party to bring to its attention any 557 copyrights, patents or patent applications, or other proprietary 558 rights that may cover technology that may be required to implement 559 this standard. Please address the information to the IETF at 560 ietf-ipr@ietf.org.