idnits 2.17.1 draft-ietf-nfsv4-rpc-netid-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 337. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 361. 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 : ---------------------------------------------------------------------------- -- 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 18, 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. '3') (Obsoleted by RFC 5531) -- Obsolete informational reference (is this intentional?): RFC 3530 (ref. '4') (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. '6') (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 760 (ref. '9') (Obsoleted by RFC 791) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '10') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 777 (ref. '11') (Obsoleted by RFC 792) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '12') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 675 (ref. '13') (Obsoleted by RFC 7805) Summary: 1 error (**), 0 flaws (~~), 2 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 18, 2008 5 Intended status: Standards Track 6 Expires: February 19, 2009 8 IANA Considerations for RPC Net Identifiers 9 draft-ietf-nfsv4-rpc-netid-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 19, 2009. 36 Abstract 38 This Internet-Draft lists IANA Considerations for RPC Network 39 Identifiers (netids). This Internet-Draft updates, but does not 40 replace, RFC1833. 42 Requirements Language 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC 2119 [1]. 48 Table of Contents 50 1. Introduction and Motivation . . . . . . . . . . . . . . . . . . 3 51 2. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 52 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 53 3.1. Initial Registry . . . . . . . . . . . . . . . . . . . . . 5 54 3.2. Updating Registrations . . . . . . . . . . . . . . . . . . 7 55 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 4.1. Normative References . . . . . . . . . . . . . . . . . . . 7 57 4.2. Informative References . . . . . . . . . . . . . . . . . . 7 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 Intellectual Property and Copyright Statements . . . . . . . . . . 9 61 1. Introduction and Motivation 63 The concept of an RPC ([3]) Network Identifier (netid) was introduced 64 in [2] for distinguishing universal network addresses of multiple 65 protocols. [2] states that a netid ``is defined by a system 66 administrator based on local conventions, and cannot be depended on 67 to have the same value on every system.'' Since the publication of 68 RFC1833, it has been found to be necessary that protocols like [4] 69 and [5] depend on consistent values of netids across every system, 70 and current practices tend to ensure this consistency. Thus, this 71 document identifies the considerations for IANA to establish a 72 registry of netids for RPC and specifies the initial content of the 73 registry. 75 2. Security Considerations 77 See section 9 of [6]. 79 3. IANA Considerations 81 This section uses terms that are defined in [6]. 83 IANA will create a registry called "ONC RPC Netids". The remainder 84 of this section describes the registry. 86 All assignments to the ONC RPC Netids registry are made on one of two 87 bases: 89 o First Come First Served basis per section 4.1 of [6]. 91 o Standards Action per section 4.1 of [6]. 93 Netids can be up to 2^32 - 1 octets in length. However, to ensure 94 that practical values for Standards Track protocols are not 95 exhausted, the values of netids one to eight octets long should be 96 used for netids assigned on the Standards Action basis. Assignments 97 made on a First Come First Served basis should be assigned netids of 98 length 9 to 128 octets long. All netids, regardless of length, that 99 start with the prefixes "STDS" or "FCFS" are Reserved, in order to 100 extend the name space of either basis. In addition, to give IESG the 101 flexibility in the future to permit Private and Experimental Uses, 102 all netids with the prefixes "PRIV" or "EXPE" are Reserved. The zero 103 length netid is Reserved. Some exceptions are listed in Table 2. A 104 recommended convention for netids corresponding to transports that 105 work over the IPv6 protocol is to have "6" as the last character in 106 the netid string name. 108 Since netids are not constructed in an explicit hierarchical manner, 109 this document does not provide for Hierarchical Allocation of netids. 110 Nonetheless, the octet "." in a netid string is Reserved for future 111 possible provision of Hierarchical Allocation. 113 The registry of netids is a list of assignments, each containing six 114 fields for each assignment made on a First Come First Served basis, 115 and five fields for each assignment made on a Standards Action basis. 116 Regardless of basis, all six fields must be provided to IANA. 118 1. A US-ASCII string name that is the actual netid. This name MUST 119 NOT conflict with any other netid. This string name can be zero 120 to 128 octets long. 122 2. A constant name that can be used for software programs that wish 123 to use the transport protocol associated with protocol. The name 124 of the constant typically has the prefix: 'NC_', and a suffix 125 equal to the upper case version of the netid. This constant name 126 should be a constant that is valid in the 'C' programming 127 language. This constant name MUST NOT conflict with any other 128 netid constant name. Constant names starting with "NC_STDS", 129 "NC_FCFS", "NC_PRIV", or "NC_EXPE" are reserved. Constant names 130 with a prefix of "NC_" and a total length of 11 characters or 131 less should be for assignments made on the Standards Action 132 basis. The constant name can be 1 to 131 octets long. 134 3. For assignments made on a First Come First Served basis a 135 description, which can be up to 1024 US-ASCII characters (or more 136 if IANA permits) how the netid will be used. For assignments 137 made on a Standards Action basis, the description field is 138 provided to the Designated Expert to enable the review, but the 139 description is not recorded in the registry, and IANA may dispose 140 of the description once IESG approves the assignment. 142 4. For assignments made on a First Come First Served basis, if 143 applicable, a reference to a published description of the 144 transport protocol (preferred), or a reference to a published use 145 of the transport protocol. This reference can consume up to 256 146 octets (or more if IANA permits). For assignments made on a 147 Standards Action basis, the RFC number of the protocol the netid 148 is associated with must be provided. 150 5. For assignments made on a First Come First Served basis, if 151 applicable, a reference to a published description of the network 152 protocol (preferred), or a reference to a published use of the 153 transport protocol. This reference can consume up to 256 octets 154 (or more if IANA permits). For assignments made on a Standards 155 Action basis, if the previous field refers to a transport 156 protocol, the RFC number of the network protocol the netid is 157 associated with must be provided. 159 6. For assignments made on a First Come First Served basis, a point 160 of contact, including an email address. The point of contact can 161 consume up to 256 octets (or more if IANA permits). Subject to 162 authorization by a Designated Expert, the point of contact may be 163 omitted for extraordinary situations, such as the registration of 164 a commonly used netid where the owner is in unknown. For 165 assignments made on a Standards Action basis the point of contact 166 is always IESG. 168 3.1. Initial Registry 170 The initial list of netids is broken into those assigned on a First 171 Come First Serve basis in Table 1 and those assigned on a Standards 172 Action basis in Table 2. These lists will change when IANA registers 173 additional netids as needed, and the authoritative list of registered 174 netids will always live with IANA. 176 +-------------+--------------+---------------------+-----+----+-----+ 177 | Netid | Constant | Description | PR | NR | PoC | 178 | | Name | | | | | 179 +-------------+--------------+---------------------+-----+----+-----+ 180 | "ticlts" | NC_TICLTS | The loop back | [7] | | | 181 | | | connectionless | | | | 182 | | | transport used in | | | | 183 | | | System V Release 4 | | | | 184 | | | and other operating | | | | 185 | | | systems. Although | | | | 186 | | | this assignment is | | | | 187 | | | made on a First | | | | 188 | | | Come First Served | | | | 189 | | | basis and is fewer | | | | 190 | | | than 9 characters | | | | 191 | | | log, the exception | | | | 192 | | | is authorized. | | | | 193 | "ticots" | NC_TICOTS | The loop back | [7] | | | 194 | | | connection-oriented | | | | 195 | | | transport used in | | | | 196 | | | System V Release 4 | | | | 197 | | | and other operating | | | | 198 | | | systems. Although | | | | 199 | | | this assignment is | | | | 200 | | | made on a First | | | | 201 | | | Come First Served | | | | 202 | | | basis and is fewer | | | | 203 | | | than 9 characters | | | | 204 | | | log, the exception | | | | 205 | | | is authorized. | | | | 206 | "ticotsord" | NC_TICOTSORD | The loop back | [7] | | | 207 | | | connection-oriented | | | | 208 | | | with | | | | 209 | | | orderly-release | | | | 210 | | | transport used in | | | | 211 | | | System V Release 4 | | | | 212 | | | and other operating | | | | 213 | | | systems. | | | | 214 +-------------+--------------+---------------------+-----+----+-----+ 216 Table 1 218 PR: Protocol Reference. NR: Network protocol Reference. PoC: Point 219 of Contact. 221 +---------+---------------+--------------+--------------+------+ 222 | Netid | Constant Name | PR | NR | PoC | 223 +---------+---------------+--------------+--------------+------+ 224 | "-" | NC_NOPROTO | RFC1833 [2] | | IESG | 225 | "dccp" | NC_DCCP | RFC4340 [8] | RFC0760 [9] | IESG | 226 | "dccp6" | NC_DCCP6 | RFC4340 [8] | RFC2460 [10] | IESG | 227 | "icmp" | NC_ICMP | RFC0777 [11] | RFC0760 [9] | IESG | 228 | "icmp6" | NC_ICMP6 | RFC0777 [11] | RFC2460 [10] | IESG | 229 | "rdma" | NC_RDMA | RFCTBD1 [5] | RFC0760 [9] | IESG | 230 | "rdma6" | NC_RDMA6 | RFCTBD1 [5] | RFC2460 [10] | IESG | 231 | "sctp" | NC_SCTP | RFC2960 [12] | RFC0760 [9] | IESG | 232 | "sctp6" | NC_SCTP6 | RFC2960 [12] | RFC2460 [10] | IESG | 233 | "tcp" | NC_TCP | RFC0675 [13] | RFC0760 [9] | IESG | 234 | "tcp6" | NC_TCP6 | RFC0675 [13] | RFC2460 [10] | IESG | 235 | "udp" | NC_UDP | RFC0768 [14] | RFC0760 [9] | IESG | 236 | "udp6" | NC_UDP6 | RFC0768 [14] | RFC2460 [10] | IESG | 237 +---------+---------------+--------------+--------------+------+ 239 Table 2 241 3.2. Updating Registrations 243 Per section 5.2 of [6] the point of contact is always permitted to 244 update a registration made on a First Come First Served basis 245 "subject to the same constraints and review as with new 246 registrations." IESG or a Designated Expert is permitted to update 247 any registration made on a First Come First Served basis, which 248 normally is done when the PoC cannot be reached in order to make 249 necessary updates. Examples where an update would be needed 250 included, but are not limited to: the email address or other contact 251 information becomes invalid; the reference to the corresponding 252 protocol becomes obsolete or unavailable; and RFC1833 [2] is updated 253 or replaced in such a way that the scope of netids changes, requiring 254 additional fields in the assignment. 256 Only IESG, on the advice of a Designated Expert, can update a 257 registration made on a Standards Action basis. 259 4. References 261 4.1. Normative References 263 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 264 Levels", RFC 2119, March 1997. 266 [2] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", 267 RFC 1833, August 1995. 269 4.2. Informative References 271 [3] Srinivasan, R., "RPC: Remote Procedure Call Protocol 272 Specification Version 2", RFC 1831, August 1995. 274 [4] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, 275 C., Eisler, M., and D. Noveck, "Network File System (NFS) 276 version 4 Protocol", RFC 3530, April 2003. 278 [5] Talpey, T. and B. Callaghan, "Remote Direct Memory Access 279 Transport for Remote Procedure Call", 280 draft-ietf-nfsv4-rpcrdma-08 (work in progress), April 2008. 282 [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 283 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 285 [7] American Telephone and Telegraph Company, "UNIX System V, 286 Release 4 Programmer's Guide: Networking Interfaces, ISBN 287 0139470786", 1990. 289 [8] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion 290 Control Protocol (DCCP)", RFC 4340, March 2006. 292 [9] Postel, J., "DoD standard Internet Protocol", RFC 760, 293 January 1980. 295 [10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 296 Specification", RFC 2460, December 1998. 298 [11] Postel, J., "Internet Control Message Protocol", RFC 777, 299 April 1981. 301 [12] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 302 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 303 Paxson, "Stream Control Transmission Protocol", RFC 2960, 304 October 2000. 306 [13] Cerf, V., Dalal, Y., and C. Sunshine, "Specification of 307 Internet Transmission Control Program", RFC 675, December 1974. 309 [14] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 310 August 1980. 312 Author's Address 314 Mike Eisler 315 NetApp 316 5765 Chase Point Circle 317 Colorado Springs, CO 80919 318 US 320 Phone: +1-719-599-9026 321 Email: mike@eisler.com 323 Full Copyright Statement 325 Copyright (C) The IETF Trust (2008). 327 This document is subject to the rights, licenses and restrictions 328 contained in BCP 78, and except as set forth therein, the authors 329 retain all their rights. 331 This document and the information contained herein are provided on an 332 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 333 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 334 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 335 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 336 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 337 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 339 Intellectual Property 341 The IETF takes no position regarding the validity or scope of any 342 Intellectual Property Rights or other rights that might be claimed to 343 pertain to the implementation or use of the technology described in 344 this document or the extent to which any license under such rights 345 might or might not be available; nor does it represent that it has 346 made any independent effort to identify any such rights. Information 347 on the procedures with respect to rights in RFC documents can be 348 found in BCP 78 and BCP 79. 350 Copies of IPR disclosures made to the IETF Secretariat and any 351 assurances of licenses to be made available, or the result of an 352 attempt made to obtain a general license or permission for the use of 353 such proprietary rights by implementers or users of this 354 specification can be obtained from the IETF on-line IPR repository at 355 http://www.ietf.org/ipr. 357 The IETF invites any interested party to bring to its attention any 358 copyrights, patents or patent applications, or other proprietary 359 rights that may cover technology that may be required to implement 360 this standard. Please address the information to the IETF at 361 ietf-ipr@ietf.org.