idnits 2.17.1 draft-ietf-nfsv4-rpc-netid-02.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 515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 539. 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 (August 19, 2008) is 5722 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) August 19, 2008 5 Intended status: Standards Track 6 Expires: February 20, 2009 8 IANA Considerations for RPC Net Identifiers and Universal Address 9 Formats 10 draft-ietf-nfsv4-rpc-netid-02.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 February 20, 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. Security Considerations . . . . . . . . . . . . . . . . . . . 3 53 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. IANA Considerations for Netids . . . . . . . . . . . . . . 3 55 3.1.1. Initial Registry . . . . . . . . . . . . . . . . . . . 5 56 3.1.2. Updating Registrations . . . . . . . . . . . . . . . . 7 57 3.2. IANA Considerations for Uaddr Formats . . . . . . . . . . 7 58 3.2.1. Initial Registry . . . . . . . . . . . . . . . . . . . 8 59 3.2.2. Updating Registrations . . . . . . . . . . . . . . . . 8 60 3.2.3. Uaddr Formats . . . . . . . . . . . . . . . . . . . . 9 61 3.3. Cross Referencing Between the Netid and Format Registry . 10 62 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 4.1. Normative References . . . . . . . . . . . . . . . . . . . 10 64 4.2. Informative References . . . . . . . . . . . . . . . . . . 10 65 Appendix A. RFC Editor Notes . . . . . . . . . . . . . . . . . . 11 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 Intellectual Property and Copyright Statements . . . . . . . . . . 13 69 1. Introduction and Motivation 71 The concepts of an RPC [4] Network Identifier (netid) and an RPC 72 Universal Address (uaddr) were introduced in [2] for distinguishing 73 network addresses of multiple protocols and representing those 74 addresses in a canonical form. [2] states that a netid ``is defined 75 by a system administrator based on local conventions, and cannot be 76 depended on to have the same value on every system.'' (The netid is 77 contained in the field r_netid of the data type rpcb_entry, and the 78 uaddr is contained in the field r_addr of the same data type, where 79 rpcb_entry is defined in [2].) Since the publication of [2], it has 80 been found to be necessary that protocols like [5] and [6] depend on 81 consistent values of netids and representations of uaddrs. Current 82 practices tend to ensure this consistency. Thus, this document 83 identifies the considerations for IANA to establish registries of 84 netids and uaddr formats for RPC and specifies the initial content of 85 the two registries. 87 2. Security Considerations 89 See section 9 of [7]. 91 3. IANA Considerations 93 This section uses terms that are defined in [7]. 95 3.1. IANA Considerations for Netids 97 IANA will create a registry called "ONC RPC Netids". The remainder 98 of this section describes the registry. 100 All assignments to the ONC RPC Netids registry are made on one of two 101 bases: 103 o First Come First Served basis per section 4.1 of [7]. 105 o Standards Action per section 4.1 of [7]. 107 Netids can be up to 2^32 - 1 octets in length. However, to ensure 108 that practical values for Standards Track protocols are not 109 exhausted, the values of netids one to eight octets long should be 110 used for netids assigned on the Standards Action basis. Assignments 111 made on a First Come First Served basis should be assigned netids of 112 length 9 to 128 octets long. All netids, regardless of length, that 113 start with the prefixes "STDS" or "FCFS" are Reserved, in order to 114 extend the name space of either basis. In addition, to give IESG the 115 flexibility in the future to permit Private and Experimental Uses, 116 all netids with the prefixes "PRIV" or "EXPE" are Reserved. The zero 117 length netid is Reserved. Some exceptions are listed in Table 2. A 118 recommended convention for netids corresponding to transports that 119 work over the IPv6 protocol is to have "6" as the last character in 120 the netid's name. 122 Since netids are not constructed in an explicit hierarchical manner, 123 this document does not provide for Hierarchical Allocation of netids. 124 Nonetheless, the octet "." in a netid string is Reserved for future 125 possible provision of Hierarchical Allocation. 127 The registry of netids is a list of assignments, each containing five 128 fields for each assignment. 130 1. A US-ASCII string name that is the actual netid. This name MUST 131 NOT conflict with any other netid. This string name can be zero 132 to 128 octets long. 134 2. A constant name that can be used for software programs that wish 135 to use the transport protocol associated with protocol. The name 136 of the constant typically has the prefix: 'NC_', and a suffix 137 equal to the upper case version of the netid. This constant name 138 should be a constant that is valid in the 'C' programming 139 language. This constant name MUST NOT conflict with any other 140 netid constant name. Constant names with the prefix "NC_STDS", 141 "NC_FCFS", "NC_PRIV", or "NC_EXPE" are reserved. Constant names 142 with a prefix of "NC_" and a total length of 11 characters or 143 less should be for assignments made on the Standards Action 144 basis. The constant name can be 1 to 131 octets long. 146 3. A description and/or a reference to a description of the how the 147 netid will be used. For assignments made on a First Come First 148 Served basis the description should include, if applicable, a 149 reference to the transport and network protocols corresponding to 150 the netid. For assignments made on a Standards Action basis, the 151 description field must include the RFC numbers of the protocol 152 associated with the netid, including if applicable, RFC numbers 153 of the transport and network protocols. This field can be up to 154 1024 octets. If more space is required, an RFC should be 155 published. 157 4. A point of contact of the registrant. The point of contact can 158 consume up to 256 octets (or more if IANA permits). For 159 assignments made on a First Come First Served basis, 161 * the point of contact should include an email address. 163 * subject to authorization by a Designated Expert, the point of 164 contact may be omitted for extraordinary situations, such as 165 the registration of a commonly used netid where the owner is 166 unknown. 168 For assignments made on a Standards Action basis the point of 169 contact is always IESG. 171 5. A numerical value, used to cross reference the netid assignment 172 with an assignment in the uaddr format registry (see 173 Section 3.2). If the registrant is registering a netid that 174 cross references an existing assignment in the uaddr format 175 registry, then the registrant provides the actual value of the 176 cross reference along with the date the registrant retrieved the 177 cross reference value from the uaddr format registry. If the 178 registrant is registering both a new netid and new uaddr format, 179 then the registrant provides a value of TBD1 in the netid 180 request, and uses TBD1 in the the uaddr format request. IANA 181 will then substitute TBD1 for cross reference number IANA 182 allocates. 184 3.1.1. Initial Registry 186 The initial list of netids is broken into those assigned on a First 187 Come First Serve basis in Table 1 and those assigned on a Standards 188 Action basis in Table 2. These lists will change when IANA registers 189 additional netids as needed, and the authoritative list of registered 190 netids will always live with IANA. 192 +-------------+--------------+---------------------------+-----+----+ 193 | Netid | Constant | Description and/or | PoC | CR | 194 | | Name | Reference | | | 195 +-------------+--------------+---------------------------+-----+----+ 196 | "-" | NC_NOPROTO | RFC1833 [2], | | 1 | 197 | | | Section 3.2.3.2 of | | | 198 | | | RFCTBD2 | | | 199 | "ticlts" | NC_TICLTS | The loop back | | 0 | 200 | | | connectionless transport | | | 201 | | | used in System V Release | | | 202 | | | 4 and other operating | | | 203 | | | systems. Although this | | | 204 | | | assignment is made on a | | | 205 | | | First Come First Served | | | 206 | | | basis and is fewer than 9 | | | 207 | | | characters long, the | | | 208 | | | exception is authorized. | | | 209 | | | See [8]. | | | 210 | "ticots" | NC_TICOTS | The loop back | | 0 | 211 | | | connection-oriented | | | 212 | | | transport used in System | | | 213 | | | V Release 4 and other | | | 214 | | | operating systems. See | | | 215 | | | [8]. Although this | | | 216 | | | assignment is made on a | | | 217 | | | First Come First Served | | | 218 | | | basis and is fewer than 9 | | | 219 | | | characters long, the | | | 220 | | | exception is authorized. | | | 221 | "ticotsord" | NC_TICOTSORD | The loop back | | 0 | 222 | | | connection-oriented with | | | 223 | | | orderly-release transport | | | 224 | | | used in System V Release | | | 225 | | | 4 and other operating | | | 226 | | | systems. See [8]. | | | 227 +-------------+--------------+---------------------------+-----+----+ 229 Table 1: Initial First Come First Serve Netid Assignments 231 PoC: Point of Contact. CR: Cross Reference to the Uaddr Format 232 Registry. 234 +---------+--------------+------------------------------+------+----+ 235 | Netid | Constant | RFC(s) and Description (if | PoC | CR | 236 | | Name | needed) | | | 237 +---------+--------------+------------------------------+------+----+ 238 | "dccp" | NC_DCCP | RFC4340 [9] RFC0760 [10] | IESG | 2 | 239 | "dccp6" | NC_DCCP6 | RFC4340 [9] RFC2460 [11] | IESG | 3 | 240 | "icmp" | NC_ICMP | RFC0777 [12] RFC0760 [10] | IESG | 4 | 241 | "icmp6" | NC_ICMP6 | RFC0777 [12] RFC2460 [11] | IESG | 4 | 242 | "rdma" | NC_RDMA | RFCTBD1 [6] RFC0760 [10] | IESG | 2 | 243 | "rdma6" | NC_RDMA6 | RFCTBD1 [6] RFC2460 [11] | IESG | 3 | 244 | "sctp" | NC_SCTP | RFC2960 [13] RFC0760 [10] | IESG | 2 | 245 | "sctp6" | NC_SCTP6 | RFC2960 [13] RFC2460 [11] | IESG | 3 | 246 | "tcp" | NC_TCP | RFC0675 [14] RFC0760 [10] | IESG | 2 | 247 | "tcp6" | NC_TCP6 | RFC0675 [14] RFC2460 [11] | IESG | 3 | 248 | "udp" | NC_UDP | RFC0768 [15] RFC0760 [10] | IESG | 2 | 249 | "udp6" | NC_UDP6 | RFC0768 [15] RFC2460 [11] | IESG | 3 | 250 +---------+--------------+------------------------------+------+----+ 252 Table 2: Initial Standards Action Netid Assignments 254 3.1.2. Updating Registrations 256 Per section 5.2 of [7] the registrant always permitted to update a 257 registration made on a First Come First Served basis "subject to the 258 same constraints and review as with new registrations." IESG or a 259 Designated Expert is permitted to update any registration made on a 260 First Come First Served basis, which normally is done when the PoC 261 cannot be reached in order to make necessary updates. Examples where 262 an update would be needed include, but are not limited to: the email 263 address or other contact information becomes invalid; the reference 264 to the corresponding protocol becomes obsolete or unavailable; and 265 RFC1833 [2] is updated or replaced in such a way that the scope of 266 netids changes, requiring additional fields in the assignment. 268 Only IESG, on the advice of a Designated Expert, can update a 269 registration made on a Standards Action basis. 271 3.2. IANA Considerations for Uaddr Formats 273 IANA will create a registry called "ONC RPC Uaddr Format Registry" 274 (called the "format registry" for the remainder of this document). 275 The remainder of this section describes the registry. 277 All assignments to the format registry are made on one of two bases: 279 o First Come First Served basis per section 4.1 of [7]. 281 o Standards Action per section 4.1 of [7]. 283 The registry of formats is a list of assignments, each containing 284 four fields for each assignment. 286 1. The basis for the assignment, which can be either FCFS for First 287 Come First Served assignments, or STDS for Standards Action 288 assignments. 290 2. A description and/or reference to a description of the actual 291 uaddr format. Assignments made on a Standards Action basis 292 always have a reference to an RFC. This field can be up to 1024 293 octets. If more space is required, an RFC should be published. 295 3. For assignments made on a First Come First Served basis, a point 296 of contact, including an email address. The point of contact can 297 consume up to 256 octets (or more if IANA permits). Subject to 298 authorization by a Designated Expert, the point of contact may be 299 omitted for extraordinary situations, such as the registration of 300 a commonly used format where the owner is unknown. For 301 assignments made on a Standards Action basis the point of contact 302 is always IESG. 304 4. A numerical value, used to cross reference the format assignment 305 with an assignment in the netid registry. The registrant 306 provides a value of TBD1 for the cross reference filed when 307 requesting an assignment. IANA will assign TBD1 to a real value. 309 All requests for assignments to the format registry must undergo 310 Expert Review. All requests for assignments made on a Standards 311 Action basis must be approved by IESG. 313 3.2.1. Initial Registry 315 The initial list of formats is in Table 3. This lists will change 316 when IANA registers additional formats as needed, and the 317 authoritative list of registered formats will always live with IANA. 319 +-------+-----------------------------------------------+------+----+ 320 | Basis | Description and/or Reference | PoC | CR | 321 +-------+-----------------------------------------------+------+----+ 322 | FCFS | System V Release 4 loopback transport uaddr | | 0 | 323 | | format. Section 3.2.3.1 of RFCTBD2 | | | 324 | FCFS | Uaddr format for NC_NOPROTO. Section 3.2.3.2 | | 1 | 325 | | of RFCTBD2 | | | 326 | STDS | Uaddr format for IPv4 transports. | IESG | 2 | 327 | | Section 3.2.3.3 of RFCTBD2 | | | 328 | STDS | Uaddr format for IPv6 transports. | IESG | 3 | 329 | | Section 3.2.3.4 of RFCTBD2 | | | 330 | STDS | Uaddr formation for ICMP. Section 3.2.3.5 of | IESG | 4 | 331 | | RFCTBD2 | | | 332 +-------+-----------------------------------------------+------+----+ 334 Table 3: Initial Format Assignments 336 3.2.2. Updating Registrations 338 The registrant always permitted to update a registration made on a 339 First Come First Served basis "subject to the same constraints and 340 review as with new registrations.", but as with new registrations, 341 any requested changes to any field other the point of contact 342 requires Expert Review. IESG or a Designated Expert is permitted to 343 update any registration made on a First Come First Served basis, 344 which normally is done when the PoC cannot be reached in order to 345 make necessary updates. Examples where an update would be needed 346 include, but are not limited to: the email address or other contact 347 information becomes invalid; the reference to the format description 348 becomes obsolete or unavailable; and RFC1833 [2] is updated or 349 replaced in such a way that the scope of uaddr formats changes, 350 requiring additional fields in the assignment. 352 Only IESG, on the advice of a Designated Expert, can update a 353 registration made on a Standards Action basis. 355 3.2.3. Uaddr Formats 357 3.2.3.1. Uaddr Format for System V Release 4 Loopback Transports 359 Although [2] identifies the uaddr as data type string (hence, limited 360 to US-ASCII), implementations of the System V Release 4 loopback 361 transports will use an opaque string of octets. Thus format of a 362 loopback transport address is any non-zero length array of octets. 364 3.2.3.2. Uaddr Format for Netid "-" 366 There is no address format for netid "-". This netid is apparently 367 for internal use for supporting some implementations of [2]. 369 3.2.3.3. Uaddr Format for Most IPv4 Transports 371 Most transport protocols that operate over IPv4 use 16 bit port 372 numbers, including DCCP [9], RDMA [6], SCTP [13], TCP [14], and UDP 373 [15]. The format of the uaddr for the above 16 bit port transports 374 (when used over IPv4) is the US-ASCII string: 376 h1.h2.h3.h4.p1.p2 378 The prefix, "h1.h2.h3.h4", is the standard textual form for 379 representing an IPv4 address, which is always four octets long. 380 Assuming big-endian ordering, h1, h2, h3, and h4, are respectively, 381 the first through fourth octets each converted to ASCII-decimal. The 382 suffix, "p1.p2", is a textual form for representing a TCP and UDP 383 service port. Assuming big-endian ordering, p1 and p2 are, 384 respectively, the first and second octets each converted to ASCII- 385 decimal. For example, if a host, in big-endian order, has an address 386 of 0x0A010307 and there is a service listening on, in big endian 387 order, port 0x020F (decimal 527), then the complete uaddr is 388 "10.1.3.7.2.15". 390 3.2.3.4. Uaddr Format for Most IPv6 Transports 392 Most transport protocols that operate over IPv6 use 16 bit port 393 numbers, including DCCP [9], RDMA [6], SCTP [13], TCP [14], and UDP 394 [15]. The format of the uaddr for the above 16 bit port transports 395 (when used over IPv6) is the US-ASCII string: 397 x1:x2:x3:x4:x5:x6:x7:x8.p1.p2 399 The suffix "p1.p2" is the service port, and is computed the same way 400 as with uaddrs for transports over IPv4 (see Section 3.2.3.3). The 401 prefix, "x1:x2:x3:x4:x5:x6:x7:x8", is the preferred textual form for 402 representing an IPv6 address as defined in Section 2.2 of [3]. 403 Additionally, the two alternative forms specified in Section 2.2 of 404 [3] are also acceptable. 406 3.2.3.5. Uaddr Format for ICMP over IPv4 and IPv6 408 As ICMP is not a true transport, there is no uaddr format for ICMP. 409 The netid assignments "icmp" and "icmp6" and their shared uaddr 410 "format" are listed to prevent any registrant from allocating the 411 netids "icmp" and "icmp6" for a purpose that would likely cause 412 confusion. 414 3.3. Cross Referencing Between the Netid and Format Registry 416 The last field of the netids registry is used to cross reference with 417 the last field of the format registry. IANA is under no obligation 418 to maintain same numeric value in cross references when updating each 419 registry; i.e. IANA is free to "re-number" these corresponding 420 fields. However, if IANA does so, both the netid and format 421 registries must be updated atomically. 423 4. References 425 4.1. Normative References 427 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 428 Levels", RFC 2119, March 1997. 430 [2] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", 431 RFC 1833, August 1995. 433 [3] Hinden, R. and S. Deering, "IP Version 6 Addressing 434 Architecture", RFC 4291, February 2006. 436 4.2. Informative References 438 [4] Srinivasan, R., "RPC: Remote Procedure Call Protocol 439 Specification Version 2", RFC 1831, August 1995. 441 [5] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, 442 C., Eisler, M., and D. Noveck, "Network File System (NFS) 443 version 4 Protocol", RFC 3530, April 2003. 445 [6] Talpey, T. and B. Callaghan, "Remote Direct Memory Access 446 Transport for Remote Procedure Call", 447 draft-ietf-nfsv4-rpcrdma-08 (work in progress), April 2008. 449 [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 450 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 452 [8] American Telephone and Telegraph Company, "UNIX System V, 453 Release 4 Programmer's Guide: Networking Interfaces, ISBN 454 0139470786", 1990. 456 [9] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion 457 Control Protocol (DCCP)", RFC 4340, March 2006. 459 [10] Postel, J., "DoD standard Internet Protocol", RFC 760, 460 January 1980. 462 [11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 463 Specification", RFC 2460, December 1998. 465 [12] Postel, J., "Internet Control Message Protocol", RFC 777, 466 April 1981. 468 [13] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 469 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 470 Paxson, "Stream Control Transmission Protocol", RFC 2960, 471 October 2000. 473 [14] Cerf, V., Dalal, Y., and C. Sunshine, "Specification of 474 Internet Transmission Control Program", RFC 675, December 1974. 476 [15] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 477 August 1980. 479 Appendix A. RFC Editor Notes 481 [RFC Editor: please remove this section prior to publication.] 483 [RFC Editor: Please replace occurrences of RFCTBD1 with the RFCxxxx 484 where xxxx is the RFC number assigned to the document referenced in 485 [6].] 487 [RFC Editor: Please replace occurrences of RFCTBD2 with the RFCyyyy 488 where yyyy is the RFC number assigned to this document.] 490 Author's Address 492 Mike Eisler 493 NetApp 494 5765 Chase Point Circle 495 Colorado Springs, CO 80919 496 US 498 Phone: +1-719-599-9026 499 Email: mike@eisler.com 501 Full Copyright Statement 503 Copyright (C) The IETF Trust (2008). 505 This document is subject to the rights, licenses and restrictions 506 contained in BCP 78, and except as set forth therein, the authors 507 retain all their rights. 509 This document and the information contained herein are provided on an 510 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 511 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 512 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 513 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 514 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 515 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 517 Intellectual Property 519 The IETF takes no position regarding the validity or scope of any 520 Intellectual Property Rights or other rights that might be claimed to 521 pertain to the implementation or use of the technology described in 522 this document or the extent to which any license under such rights 523 might or might not be available; nor does it represent that it has 524 made any independent effort to identify any such rights. Information 525 on the procedures with respect to rights in RFC documents can be 526 found in BCP 78 and BCP 79. 528 Copies of IPR disclosures made to the IETF Secretariat and any 529 assurances of licenses to be made available, or the result of an 530 attempt made to obtain a general license or permission for the use of 531 such proprietary rights by implementers or users of this 532 specification can be obtained from the IETF on-line IPR repository at 533 http://www.ietf.org/ipr. 535 The IETF invites any interested party to bring to its attention any 536 copyrights, patents or patent applications, or other proprietary 537 rights that may cover technology that may be required to implement 538 this standard. Please address the information to the IETF at 539 ietf-ipr@ietf.org.