idnits 2.17.1 draft-ietf-nfsv4-rpc-netid-04.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 526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 537. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 550. 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 3, 2008) is 5615 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) == Outdated reference: A later version (-09) exists of draft-ietf-nfsv4-rpcrdma-08 -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. '7') (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 760 (ref. '10') (Obsoleted by RFC 791) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '11') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 777 (ref. '12') (Obsoleted by RFC 792) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '13') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 675 (ref. '14') (Obsoleted by RFC 7805) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 16 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 3, 2008 5 Intended status: Standards Track 6 Expires: June 6, 2009 8 IANA Considerations for RPC Net Identifiers and Universal Address 9 Formats 10 draft-ietf-nfsv4-rpc-netid-04.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 6, 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 . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 5.1. Normative References . . . . . . . . . . . . . . . . . . . 11 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 and Juergen Schoenwaelder reviewed the document and gave 92 valuable feed back for improving its readability. 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 First Come First Served basis per section 4.1 of RFC5226. 114 o Standards Action per section 4.1 of RFC5226. 116 Netids can be up to 2^32 - 1 octets in length. However, to ensure 117 that practical values for Standards Track protocols are not 118 exhausted, the values of netids one to eight octets long should be 119 used for netids assigned on the Standards Action basis. Assignments 120 made on a First Come First Served basis should be assigned netids of 121 length 9 to 128 octets long. All netids, regardless of length, that 122 start with the prefixes "STDS" or "FCFS" are Reserved, in order to 123 extend the name space of either basis. In addition, to give IESG the 124 flexibility in the future to permit Private and Experimental Uses, 125 all netids with the prefixes "PRIV" or "EXPE" are Reserved. The zero 126 length netid is Reserved. Some exceptions are listed in Table 2. A 127 recommended convention for netids corresponding to transports that 128 work over the IPv6 protocol is to have "6" as the last character in 129 the netid's name. 131 Since netids are not constructed in an explicit hierarchical manner, 132 this document does not provide for Hierarchical Allocation of netids. 133 Nonetheless, the octet "." in a netid string is Reserved for future 134 possible provision of Hierarchical Allocation. 136 The registry of netids is a list of assignments, each containing five 137 fields for each assignment. 139 1. A US-ASCII string name that is the actual netid. This name MUST 140 NOT conflict with any other netid. This string name can be 1 to 141 128 octets long. 143 2. A constant name that can be used for software programs that wish 144 to use the transport protocol associated with protocol. The name 145 of the constant typically has the prefix: 'NC_', and a suffix 146 equal to the upper case version of the netid. This constant name 147 should be a constant that is valid in the 'C' programming 148 language. This constant name MUST NOT conflict with any other 149 netid constant name. Constant names with the prefix "NC_STDS", 150 "NC_FCFS", "NC_PRIV", or "NC_EXPE" are reserved. Constant names 151 with a prefix of "NC_" and a total length of 11 characters or 152 less should be for assignments made on the Standards Action 153 basis. The constant name can be 1 to 131 octets long. 155 3. A description and/or a reference to a description of the how the 156 netid will be used. For assignments made on a First Come First 157 Served basis the description should include, if applicable, a 158 reference to the transport and network protocols corresponding to 159 the netid. For assignments made on a Standards Action basis, the 160 description field must include the RFC numbers of the protocol 161 associated with the netid, including if applicable, RFC numbers 162 of the transport and network protocols. This field can be up to 163 1024 octets. If more space is required, an RFC should be 164 published. 166 4. A point of contact of the registrant. The point of contact can 167 consume up to 256 octets (or more if IANA permits). For 168 assignments made on a First Come First Served basis, 170 * the point of contact should include an email address. 172 * subject to authorization by a Designated Expert, the point of 173 contact may be omitted for extraordinary situations, such as 174 the registration of a commonly used netid where the owner is 175 unknown. 177 For assignments made on a Standards Action basis the point of 178 contact is always IESG. 180 5. A numerical value, used to cross reference the netid assignment 181 with an assignment in the uaddr format registry (see 182 Section 4.2). If the registrant is registering a netid that 183 cross references an existing assignment in the uaddr format 184 registry, then the registrant provides the actual value of the 185 cross reference along with the date the registrant retrieved the 186 cross reference value from the uaddr format registry. If the 187 registrant is registering both a new netid and new uaddr format, 188 then the registrant provides a value of TBD1 in the netid 189 request, and uses TBD1 in the the uaddr format request. IANA 190 will then substitute TBD1 for cross reference number IANA 191 allocates. 193 4.1.1. Initial Registry 195 The initial list of netids is broken into those assigned on a First 196 Come First Serve basis in Table 1 and those assigned on a Standards 197 Action basis in Table 2. These lists will change when IANA registers 198 additional netids as needed, and the authoritative list of registered 199 netids will always live with IANA. 201 +-------------+--------------+---------------------------+-----+----+ 202 | Netid | Constant | Description and/or | PoC | CR | 203 | | Name | Reference | | | 204 +-------------+--------------+---------------------------+-----+----+ 205 | "-" | NC_NOPROTO | RFC1833 [2], | | 1 | 206 | | | Section 4.2.3.2 of | | | 207 | | | RFCTBD2 | | | 208 | "ticlts" | NC_TICLTS | The loop back | | 0 | 209 | | | connectionless transport | | | 210 | | | used in System V Release | | | 211 | | | 4 and other operating | | | 212 | | | systems. Although this | | | 213 | | | assignment is made on a | | | 214 | | | First Come First Served | | | 215 | | | basis and is fewer than 9 | | | 216 | | | characters long, the | | | 217 | | | exception is authorized. | | | 218 | | | See [8]. | | | 219 | "ticots" | NC_TICOTS | The loop back | | 0 | 220 | | | connection-oriented | | | 221 | | | transport used in System | | | 222 | | | V Release 4 and other | | | 223 | | | operating systems. See | | | 224 | | | [8]. Although this | | | 225 | | | assignment is made on a | | | 226 | | | First Come First Served | | | 227 | | | basis and is fewer than 9 | | | 228 | | | characters long, the | | | 229 | | | exception is authorized. | | | 230 | "ticotsord" | NC_TICOTSORD | The loop back | | 0 | 231 | | | connection-oriented with | | | 232 | | | orderly-release transport | | | 233 | | | used in System V Release | | | 234 | | | 4 and other operating | | | 235 | | | systems. See [8]. | | | 236 +-------------+--------------+---------------------------+-----+----+ 238 Table 1: Initial First Come First Serve Netid Assignments 240 PoC: Point of Contact. CR: Cross Reference to the Uaddr Format 241 Registry. 243 +---------+--------------+------------------------------+------+----+ 244 | Netid | Constant | RFC(s) and Description (if | PoC | CR | 245 | | Name | needed) | | | 246 +---------+--------------+------------------------------+------+----+ 247 | "dccp" | NC_DCCP | RFC4340 [9] RFC0760 [10] | IESG | 2 | 248 | "dccp6" | NC_DCCP6 | RFC4340 [9] RFC2460 [11] | IESG | 3 | 249 | "icmp" | NC_ICMP | RFC0777 [12] RFC0760 [10] | IESG | 4 | 250 | "icmp6" | NC_ICMP6 | RFC0777 [12] RFC2460 [11] | IESG | 4 | 251 | "rdma" | NC_RDMA | RFCTBD1 [6] RFC0760 [10] | IESG | 2 | 252 | "rdma6" | NC_RDMA6 | RFCTBD1 [6] RFC2460 [11] | IESG | 3 | 253 | "sctp" | NC_SCTP | RFC2960 [13] RFC0760 [10] | IESG | 2 | 254 | "sctp6" | NC_SCTP6 | RFC2960 [13] RFC2460 [11] | IESG | 3 | 255 | "tcp" | NC_TCP | RFC0675 [14] RFC0760 [10] | IESG | 2 | 256 | "tcp6" | NC_TCP6 | RFC0675 [14] RFC2460 [11] | IESG | 3 | 257 | "udp" | NC_UDP | RFC0768 [15] RFC0760 [10] | IESG | 2 | 258 | "udp6" | NC_UDP6 | RFC0768 [15] RFC2460 [11] | IESG | 3 | 259 +---------+--------------+------------------------------+------+----+ 261 Table 2: Initial Standards Action Netid Assignments 263 4.1.2. Updating Registrations 265 Per section 5.2 of RFC5226 the registrant is always permitted to 266 update a registration made on a First Come First Served basis 267 "subject to the same constraints and review as with new 268 registrations." IESG or a Designated Expert is permitted to update 269 any registration made on a First Come First Served basis, which 270 normally is done when the PoC cannot be reached in order to make 271 necessary updates. Examples where an update would be needed include, 272 but are not limited to: the email address or other contact 273 information becomes invalid; the reference to the corresponding 274 protocol becomes obsolete or unavailable; and RFC1833 is updated or 275 replaced in such a way that the scope of netids changes, requiring 276 additional fields in the assignment. 278 Only IESG, on the advice of a Designated Expert, can update a 279 registration made on a Standards Action basis. 281 4.2. IANA Considerations for Uaddr Formats 283 IANA will create a registry called "ONC RPC Uaddr Format Registry" 284 (called the "format registry" for the remainder of this document). 285 The remainder of this section describes the registry. 287 All assignments to the format registry are made on one of two bases: 289 o First Come First Served basis per section 4.1 of RFC5226. 291 o Standards Action per section 4.1 of RFC5226. 293 The registry of formats is a list of assignments, each containing 294 four fields for each assignment. 296 1. The basis for the assignment, which can be either FCFS for First 297 Come First Served assignments, or STDS for Standards Action 298 assignments. 300 2. A description and/or reference to a description of the actual 301 uaddr format. Assignments made on a Standards Action basis 302 always have a reference to an RFC. This field can be up to 1024 303 octets. If more space is required, an RFC should be published. 305 3. For assignments made on a First Come First Served basis, a point 306 of contact, including an email address. The point of contact can 307 consume up to 256 octets (or more if IANA permits). Subject to 308 authorization by a Designated Expert, the point of contact may be 309 omitted for extraordinary situations, such as the registration of 310 a commonly used format where the owner is unknown. For 311 assignments made on a Standards Action basis the point of contact 312 is always IESG. 314 4. A numerical value, used to cross reference the format assignment 315 with an assignment in the netid registry. The registrant 316 provides a value of TBD1 for the cross reference filed when 317 requesting an assignment. IANA will assign TBD1 to a real value. 319 All requests for assignments to the format registry must undergo 320 Expert Review. All requests for assignments made on a Standards 321 Action basis must be approved by IESG. 323 4.2.1. Initial Registry 325 The initial list of formats is in Table 3. This lists will change 326 when IANA registers additional formats as needed, and the 327 authoritative list of registered formats will always live with IANA. 329 +-------+-----------------------------------------------+------+----+ 330 | Basis | Description and/or Reference | PoC | CR | 331 +-------+-----------------------------------------------+------+----+ 332 | FCFS | System V Release 4 loopback transport uaddr | | 0 | 333 | | format. Section 4.2.3.1 of RFCTBD2 | | | 334 | FCFS | Uaddr format for NC_NOPROTO. Section 4.2.3.2 | | 1 | 335 | | of RFCTBD2 | | | 336 | STDS | Uaddr format for IPv4 transports. | IESG | 2 | 337 | | Section 4.2.3.3 of RFCTBD2 | | | 338 | STDS | Uaddr format for IPv6 transports. | IESG | 3 | 339 | | Section 4.2.3.4 of RFCTBD2 | | | 340 | STDS | Uaddr formation for ICMP. Section 4.2.3.5 of | IESG | 4 | 341 | | RFCTBD2 | | | 342 +-------+-----------------------------------------------+------+----+ 344 Table 3: Initial Format Assignments 346 4.2.2. Updating Registrations 348 The registrant is always permitted to update a registration made on a 349 First Come First Served basis "subject to the same constraints and 350 review as with new registrations.", but as with new registrations, 351 any requested changes to any field other the point of contact 352 requires Expert Review. IESG or a Designated Expert is permitted to 353 update any registration made on a First Come First Served basis, 354 which normally is done when the PoC cannot be reached in order to 355 make necessary updates. Examples where an update would be needed 356 include, but are not limited to: the email address or other contact 357 information becomes invalid; the reference to the format description 358 becomes obsolete or unavailable; and RFC1833 is updated or replaced 359 in such a way that the scope of uaddr formats changes, requiring 360 additional fields in the assignment. 362 Only IESG, on the advice of a Designated Expert, can update a 363 registration made on a Standards Action basis. 365 4.2.3. Uaddr Formats 367 4.2.3.1. Uaddr Format for System V Release 4 Loopback Transports 369 Although RFC1833 specifies the uaddr as the XDR data type string 370 (hence, limited to US-ASCII), implementations of the System V Release 371 4 loopback transports will use an opaque string of octets. Thus the 372 format of a loopback transport address is any non-zero length array 373 of octets. 375 4.2.3.2. Uaddr Format for Netid "-" 377 There is no address format for netid "-". This netid is apparently 378 for internal use for supporting some implementations of RFC1833. 380 4.2.3.3. Uaddr Format for Most IPv4 Transports 382 Most transport protocols that operate over IPv4 use 16 bit port 383 numbers, including DCCP [9], RDMA [6], SCTP [13], TCP [14], and UDP 384 [15]. The format of the uaddr for the above 16 bit port transports 385 (when used over IPv4) is the US-ASCII string: 387 h1.h2.h3.h4.p1.p2 389 The prefix, "h1.h2.h3.h4", is the standard textual form for 390 representing an IPv4 address, which is always four octets long. 391 Assuming big-endian ordering, h1, h2, h3, and h4, are respectively, 392 the first through fourth octets each converted to ASCII-decimal. The 393 suffix, "p1.p2", is a textual form for representing a service port. 394 Assuming big-endian ordering, p1 and p2 are, respectively, the first 395 and second octets each converted to ASCII-decimal. For example, if a 396 host, in big-endian order, has an address in hexadecimal of 397 0xC0000207 and there is a service listening on, in big endian order, 398 port 0xCB51 (decimal 52049) then the complete uaddr is 399 "192.0.2.7.203.81". 401 4.2.3.4. Uaddr Format for Most IPv6 Transports 403 Most transport protocols that operate over IPv6 use 16 bit port 404 numbers, including DCCP [9], RDMA [6], SCTP [13], TCP [14], and UDP 405 [15]. The format of the uaddr for the above 16 bit port transports 406 (when used over IPv6) is the US-ASCII string: 408 x1:x2:x3:x4:x5:x6:x7:x8.p1.p2 410 The suffix "p1.p2" is the service port, and is computed the same way 411 as with uaddrs for transports over IPv4 (see Section 4.2.3.3). The 412 prefix, "x1:x2:x3:x4:x5:x6:x7:x8", is the preferred textual form for 413 representing an IPv6 address as defined in Section 2.2 of RFC4291 414 [3]. Additionally, the two alternative forms specified in Section 415 2.2 of RFC4291 are also acceptable. 417 4.2.3.5. Uaddr Format for ICMP over IPv4 and IPv6 419 As ICMP is not a true transport, there is no uaddr format for ICMP. 420 The netid assignments "icmp" and "icmp6" and their shared uaddr 421 "format" are listed to prevent any registrant from allocating the 422 netids "icmp" and "icmp6" for a purpose that would likely cause 423 confusion. 425 4.3. Cross Referencing Between the Netid and Format Registry 427 The last field of the netids registry is used to cross reference with 428 the last field of the format registry. IANA is under no obligation 429 to maintain same numeric value in cross references when updating each 430 registry; i.e. IANA is free to "re-number" these corresponding 431 fields. However, if IANA does so, both the netid and format 432 registries must be updated atomically. 434 5. References 436 5.1. Normative References 438 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 439 Levels", RFC 2119, March 1997. 441 [2] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", 442 RFC 1833, August 1995. 444 [3] Hinden, R. and S. Deering, "IP Version 6 Addressing 445 Architecture", RFC 4291, February 2006. 447 5.2. Informative References 449 [4] Srinivasan, R., "RPC: Remote Procedure Call Protocol 450 Specification Version 2", RFC 1831, August 1995. 452 [5] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, 453 C., Eisler, M., and D. Noveck, "Network File System (NFS) 454 version 4 Protocol", RFC 3530, April 2003. 456 [6] Talpey, T. and B. Callaghan, "Remote Direct Memory Access 457 Transport for Remote Procedure Call", 458 draft-ietf-nfsv4-rpcrdma-08 (work in progress), April 2008. 460 [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 461 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 463 [8] American Telephone and Telegraph Company, "UNIX System V, 464 Release 4 Programmer's Guide: Networking Interfaces, ISBN 465 0139470786", 1990. 467 [9] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion 468 Control Protocol (DCCP)", RFC 4340, March 2006. 470 [10] Postel, J., "DoD standard Internet Protocol", RFC 760, 471 January 1980. 473 [11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 474 Specification", RFC 2460, December 1998. 476 [12] Postel, J., "Internet Control Message Protocol", RFC 777, 477 April 1981. 479 [13] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 480 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 481 Paxson, "Stream Control Transmission Protocol", RFC 2960, 482 October 2000. 484 [14] Cerf, V., Dalal, Y., and C. Sunshine, "Specification of 485 Internet Transmission Control Program", RFC 675, December 1974. 487 [15] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 488 August 1980. 490 Appendix A. RFC Editor Notes 492 [RFC Editor: please remove this section prior to publication.] 494 [RFC Editor: Please replace occurrences of RFCTBD1 with the RFCxxxx 495 where xxxx is the RFC number assigned to the document referenced in 496 [6].] 498 [RFC Editor: Please replace occurrences of RFCTBD2 with the RFCyyyy 499 where yyyy is the RFC number assigned to this document.] 501 Author's Address 503 Mike Eisler 504 NetApp 505 5765 Chase Point Circle 506 Colorado Springs, CO 80919 507 US 509 Phone: +1-719-599-9026 510 Email: mike@eisler.com 512 Full Copyright Statement 514 Copyright (C) The IETF Trust (2008). 516 This document is subject to the rights, licenses and restrictions 517 contained in BCP 78, and except as set forth therein, the authors 518 retain all their rights. 520 This document and the information contained herein are provided on an 521 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 522 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 523 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 524 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 525 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 526 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 528 Intellectual Property 530 The IETF takes no position regarding the validity or scope of any 531 Intellectual Property Rights or other rights that might be claimed to 532 pertain to the implementation or use of the technology described in 533 this document or the extent to which any license under such rights 534 might or might not be available; nor does it represent that it has 535 made any independent effort to identify any such rights. Information 536 on the procedures with respect to rights in RFC documents can be 537 found in BCP 78 and BCP 79. 539 Copies of IPR disclosures made to the IETF Secretariat and any 540 assurances of licenses to be made available, or the result of an 541 attempt made to obtain a general license or permission for the use of 542 such proprietary rights by implementers or users of this 543 specification can be obtained from the IETF on-line IPR repository at 544 http://www.ietf.org/ipr. 546 The IETF invites any interested party to bring to its attention any 547 copyrights, patents or patent applications, or other proprietary 548 rights that may cover technology that may be required to implement 549 this standard. Please address the information to the IETF at 550 ietf-ipr@ietf.org.