idnits 2.17.1 draft-daniele-iana-addr-mib-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 485 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 25 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** There are 29 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 143: '...s to this module MUST be reviewed by a...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 295 has weird spacing: '... octets cont...' == Line 310 has weird spacing: '... octets cont...' == Line 311 has weird spacing: '...address net...' == Line 325 has weird spacing: '...ndpoint stri...' == Line 338 has weird spacing: '... octets cont...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 1998) is 9354 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) -- Looks like a reference, but probably isn't: '1' on line 43 -- Looks like a reference, but probably isn't: '2' on line 48 -- Looks like a reference, but probably isn't: '3' on line 48 -- Looks like a reference, but probably isn't: '4' on line 48 -- Looks like a reference, but probably isn't: '5' on line 49 -- Looks like a reference, but probably isn't: '6' on line 49 -- Looks like a reference, but probably isn't: '7' on line 50 -- Looks like a reference, but probably isn't: '8' on line 62 -- Looks like a reference, but probably isn't: '9' on line 56 -- Looks like a reference, but probably isn't: '10' on line 58 -- Looks like a reference, but probably isn't: '11' on line 58 -- Looks like a reference, but probably isn't: '12' on line 58 -- Looks like a reference, but probably isn't: '13' on line 63 -- Looks like a reference, but probably isn't: '14' on line 65 -- Looks like a reference, but probably isn't: '15' on line 67 == Unused Reference: 'RFC2257' is defined on line 431, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 432, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1902 (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2257 (Obsoleted by RFC 2741) -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-CONSIDERATIONS' Summary: 14 errors (**), 0 flaws (~~), 10 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft IANA Address MIB September 1998 2 Expires March, 1999 4 IANA Address MIB 6 8 Mike Daniele 9 Compaq Computer Corporation 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 "work in progress." 24 To view the entire list of current Internet-Drafts, please check 25 the "1id-abstracts.txt" listing contained in the Internet-Drafts 26 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 27 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 28 Coast), or ftp.isi.edu (US West Coast). 30 1. Abstract 32 This document contains an initial version of a MIB module for 33 commonly used network addressing information. It defines a registry 34 for identifiers that identify protocols and a set of textual 35 conventions for representing addresses. This document also 36 establishes IANA as the maintainer of this registry. 38 2. The SNMP Management Framework 40 The SNMP Management Framework presently consists of five major 41 components: 43 o An overall architecture, described in RFC 2271 [1]. 45 o Mechanisms for describing and naming objects and events for the 46 purpose of management. The first version of this Structure of 47 Management Information (SMI) is called SMIv1 and described in 48 RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, 49 called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 50 1904 [7]. 52 o Message protocols for transferring management information. The 53 first version of the SNMP message protocol is called SNMPv1 and 54 described in RFC 1157 [8]. A second version of the SNMP message 55 protocol, which is not an Internet standards track protocol, is 56 called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. 57 The third version of the message protocol is called SNMPv3 and 58 described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. 60 o Protocol operations for accessing management information. The 61 first set of protocol operations and associated PDU formats is 62 described in RFC 1157 [8]. A second set of protocol operations 63 and associated PDU formats is described in RFC 1905 [13]. 65 o A set of fundamental applications described in RFC 2273 [14] and 66 the view-based access control mechanism described in RFC 2275 67 [15]. 69 Managed objects are accessed via a virtual information store, termed 70 the Management Information Base or MIB. Objects in the MIB are 71 defined using the mechanisms defined in the SMI. 73 This memo specifies a MIB module that is compliant to the SMIv2. A 74 MIB conforming to the SMIv1 can be produced through the appropriate 75 translations. The resulting translated MIB must be semantically 76 equivalent, except where objects or events are omitted because no 77 translation is possible (use of Counter64). Some machine readable 78 information in SMIv2 will be converted into textual descriptions in 79 SMIv1 during the translation process. However, this loss of machine 80 readable information is not considered to change the semantics of the 81 MIB. 83 3. Overview 85 This MIB module contains definitions for commonly used network 86 addressing information. In particular, it defines a registry of 87 OBJECT-IDENTIFIERs for protocols, and a set of textual conventions 88 for representing endpoints. The former are intended to be widely 89 used as values for OBJECT-TYPEs whose syntax is TDomain, the latter 90 as values for OBJECT-TYPEs whose syntax is TAddress. 92 The purpose of this memo is to provide a single, well-known repository 93 for address-related information. Further, this module establishes IANA 94 as the maintainer of these definitions (see section 6). 96 Without such a repository, each MIB module requiring addressing constructs 97 is forced to either define its own, or attempt to locate and include similar 98 definitions from other modules. The advantages of a repository are 100 a) there is a single set of definitions 101 b) all MIB developers know what to include, and where to look 102 c) multiple definitions of the same information is avoided 103 d) the definitions are independant and widely useable, not tied 104 to a particular protocol, MIB module, or enterprise 105 e) this module can be updated independently, and hence much more 106 rapidly, than if the information is defined in broader RFCs 107 on the standards-track (for example, [RFC1906]) 109 4. Transport Domains and Addresses 111 The TDomain and TAddress textual conventions are defined in [RFC1903], 112 and are intended to be used in MIB modules to represent transport 113 domains and addresses. 115 Actual values for OBJECT-TYPEs with these syntaxes are currently defined 116 in [RFC1906] and various other (enterprise-specific) modules. 117 The transport domains defined in [RFC1906] all contain "snmp" as the prefix 118 in their name, are all assigned under `snmpDomains' (from [RFC1902]). 119 There has been some confusion as to whether these defintions are 120 appropriate for designating transport endpoints for non-SNMP traffic. 121 These definitions are also now incomplete, new transport addresses are 122 needed currently to support (at least) IPv6, TCP, and Unix-domain sockets. 124 This module defines a new set of generic transport domains and addresses. 125 All assignments are made under a new branch; (TBD), to be administered 126 by IANA. 128 5. Impact on Transport Mappings 130 This module does NOT define the transport mappings for any particular 131 protocol. Rather, it defines a set of common identifiers and textual 132 conventions that are intended to be used within various transport mappings 133 documents. 135 (Inclusion within transport mappings is just one possible use of 136 these generic definitions.) 138 6. IANA Considerations 140 It is intended that IANA will maintain this MIB module. 142 Following the policies outlined in [IANA-CONSIDERATIONS], 143 additions to this module MUST be reviewed by a Designated Expert. 145 7. Definitions 147 IANA-ADDRESS-MIB DEFINITIONS ::= BEGIN 149 IMPORTS 150 MODULE-IDENTITY, OBJECT-IDENTITY FROM SNMPv2-SMI 151 TEXTUAL-CONVENTION FROM SNMPv2-TC; 153 ianaAddressMIB MODULE-IDENTITY 154 LAST-UPDATED "9809180000Z" 155 ORGANIZATION "IANA" 156 CONTACT-INFO "TBD" 157 DESCRIPTION 158 "The MIB module for commonly-used network addressing definitions." 159 ::= { TBD } 161 -- 162 -- The registration node for protocol domains 163 -- 164 ianaAddrDomains OBJECT IDENTIFIER ::= { TBD } 166 -- 167 -- Protocol domains 168 -- 170 -- UDP over IPv4 172 ianaAddrUDPIPv4Domain OBJECT-IDENTITY 173 STATUS current 174 DESCRIPTION 175 "The UDP over IPv4 transport domain. The corresponding 176 transport address is of type IanaAddrIPv4TAddress." 177 ::= { ianaAddrDomains 1 } 179 -- UDP over IPv6 181 ianaAddrUDPIPv6Domain OBJECT-IDENTITY 182 STATUS current 183 DESCRIPTION 184 "The UDP over IPv6 transport domain. The corresponding 185 transport address is of type IanaAddrIPv6TAddress." 186 ::= { ianaAddrDomains 2 } 188 -- TCP over IPv4 190 ianaAddrTCPIPv4Domain OBJECT-IDENTITY 191 STATUS current 192 DESCRIPTION 193 "The TCP over IPv4 transport domain. The corresponding 194 transport address is of type IanaAddrIPv4TAddress." 195 ::= { ianaAddrDomains 3 } 197 -- TCP over IPv6 199 ianaAddrTCPIPv6Domain OBJECT-IDENTITY 200 STATUS current 201 DESCRIPTION 202 "The TCP over IPv6 transport domain. The corresponding 203 transport address is of type IanaAddrIPv6TAddress." 204 ::= { ianaAddrDomains 4 } 206 -- UNIX-domain sockets 208 ianaAddrUNIXDomain OBJECT-IDENTITY 209 STATUS current 210 DESCRIPTION 211 "The unix-domain sockets transport domain. The corresponding 212 transport address is of type IanaAddrUNIXTAddress." 213 ::= { ianaAddrDomains 5 } 215 -- OSI 217 ianaAddrCLNSDomain OBJECT-IDENTITY 218 STATUS current 219 DESCRIPTION 220 "The CLNS transport domain. The corresponding 221 transport address is of type IanaAddrOSITAddress." 222 ::= { ianaAddrDomains 6 } 224 ianaAddrCONSDomain OBJECT-IDENTITY 225 STATUS current 226 DESCRIPTION 227 "The CONS transport domain. The corresponding 228 transport address is of type IanaAddrOSITAddress." 229 ::= { ianaAddrDomains 7 } 231 -- DDP 233 ianaAddrDDPDomain OBJECT-IDENTITY 234 STATUS current 235 DESCRIPTION 236 "The DDP transport domain. The corresponding 237 transport address is of type IanaAddrNBPTAddress." 238 ::= { ianaAddrDomains 8 } 240 -- IPX 242 ianaAddrIPXDomain OBJECT-IDENTITY 243 STATUS current 244 DESCRIPTION 245 "The IPX transport domain. The corresponding 246 transport address is of type IanaAddrIPXTAddress." 247 ::= { ianaAddrDomains 9 } 249 -- 250 -- Enumerated integer version of previous registrations. 251 -- 252 -- This TC can be used to represent transport domains in situations 253 -- where a syntax of TDomain is unwieldy (for example, when 254 -- used as an index). 255 -- 256 -- Currently the enumerated values of this object are identical to the 257 -- last sub-identifier of the OID registered for the same domain. 258 -- 260 IanaAddrTDomainType ::= TEXTUAL-CONVENTION 261 DISPLAY-HINT "1d" 262 STATUS current 263 DESCRIPTION 264 "A value that represents a transport domain." 265 SYNTAX INTEGER { 266 other(0), 267 ianaAddrUDPIPv4Domain(1), 268 ianaAddrUDPIPv6Domain(2), 269 ianaAddrTCPIPv4Domain(3), 270 ianaAddrTCPIPv6Domain(4), 271 ianaAddrUNIXDomain(5), 272 ianaAddrCLNSDomain(6), 273 ianaAddrCONSDomain(7), 274 ianaAddrDDPDomain(8), 275 ianaAddrIPXDomain(9) 276 } 278 -- 279 -- Textual conventions for transport endpoints. 280 -- 281 -- These are named xxxTAddress to denote transport addresses, 282 -- and differentiate them from network addresses that may be included 283 -- in subsequent versions. 284 -- 286 -- TCP/UDP over IPv4 Transport Address 288 IanaAddrIPv4TAddress ::= TEXTUAL-CONVENTION 289 DISPLAY-HINT "1d.1d.1d.1d/2d" 290 STATUS current 291 DESCRIPTION 292 "Represents a TCP-over-IPv4 or a UDP-over-IPv4 293 transport address: 295 octets contents encoding 296 1-4 IP address network-byte order 297 5-6 TCP or UDP port network-byte order 298 " 299 SYNTAX OCTET STRING (SIZE (6)) 301 -- TCP/UDP over IPv6 Transport Address 303 IanaAddrIPv6TAddress ::= TEXTUAL-CONVENTION 304 DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x/2d" 305 STATUS current 306 DESCRIPTION 307 "Represents a TCP-over-IPv6 or a UDP-over-IPv6 308 transport address: 310 octets contents encoding 311 1-16 IPv6 address network-byte order 312 17-18 TCP or UDP port network-byte order 313 " 314 SYNTAX OCTET STRING (SIZE (18)) 316 -- UNIX-domain socket Transport Address 318 IanaAddrUNIXTAddress ::= TEXTUAL-CONVENTION 319 DISPLAY-HINT "1a" 320 STATUS current 321 DESCRIPTION 322 "Represents a UNIX-domain socket endpoint: 324 octets contents encoding 325 all UNIX domain endpoint string 327 " 328 SYNTAX OCTET STRING 330 -- OSI Transport Address 332 IanaAddrOSITAddress ::= TEXTUAL-CONVENTION 333 DISPLAY-HINT "*1x:/1x:" 334 STATUS current 335 DESCRIPTION 336 "Represents an OSI transport-address: 338 octets contents encoding 339 1 length of NSAP 'n' as an unsigned-integer 340 (either 0 or from 3 to 20) 341 2..(n+1) NSAP concrete binary representation 342 (n+2)..m TSEL string of (up to 64) octets 343 " 344 SYNTAX OCTET STRING (SIZE (1 | 4..85)) 346 -- NBP Transport Address 348 IanaAddrNBPTAddress ::= TEXTUAL-CONVENTION 349 STATUS current 350 DESCRIPTION 351 "Represents an NBP name: 353 octets contents encoding 354 1 length of object 'n' as an unsigned integer 355 2..(n+1) object string of (up to 32) octets 356 n+2 length of type 'p' as an unsigned integer 357 (n+3)..(n+2+p) type string of (up to 32) octets 358 n+3+p length of zone 'q' as an unsigned integer 359 (n+4+p)..(n+3+p+q) zone string of (up to 32) octets 361 For comparison purposes, strings are case-insensitive. All 362 strings may contain any octet other than 255 (hex ff)." 363 SYNTAX OCTET STRING (SIZE (3..99)) 365 -- IPX Transport Address 367 IanaAddrIPXTTAddress ::= TEXTUAL-CONVENTION 368 DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d" 369 STATUS current 370 DESCRIPTION 371 "Represents an IPX address: 373 octets contents encoding 374 1-4 network-number network-byte order 375 5-10 physical-address network-byte order 376 11-12 socket-number network-byte order 377 " 378 SYNTAX OCTET STRING (SIZE (12)) 380 END 382 8. Open Issues 384 1) Can the TDomain and TAddress textual conventions defined 385 in RFC 1903 be used to represent "generic" transport information, 386 used by applications other than just SNMP? 388 Proposal: While their definitions use detailed examples 389 that are SNMP-specific, they may be used more widely. 390 (An update to RFC1903 should modify their descriptions accordingly.) 392 2) Can the IANA-ADDRESS-MIB also be used for non-transport 393 addresses? For example, can a TAddress be used to represent 394 just a network-layer address? 396 Proposal: Yes, it can be used for arbitrary address domains. We 397 should clarify the wordings of the TDomain and TAddress 398 definition in the successor of RFC 1903 to make that clear. This 399 needs to be discussed with the work currently going on to bring 400 RFC 1903 to full standard status. 402 3) Do we need an OID where IANA controlled MIB modules such as this 403 module can be registered? (Another such module might be 404 the IANA-LANGUAGE-MIB from the DISMAN WG.) 406 Proposal: Yes. One possible node is 408 iana OBJECT IDENTIFIER ::= { internet 7 } 410 Whatever assignment is made, it should optimally be reflected in the 411 revision of RFC 1902 which is currently being worked on. 413 4) Should there be separate OID branches for network (and below) addresses, 414 network+transport addresses, and applications? 415 Or is some other hierarchy more useful? 417 Proposal: No. 419 5) If this memo prospers, what happens to the values defined in RFC1906? 421 9. Acknowledgements 423 Many of the definitions in this module are taken directly from [RFC1906]. 424 Thanks to Juergen Schoenwaelder and Mark Ellison for ideas and review to date. 426 10. References 428 [RFC1902] 429 [RFC1903] 430 [RFC1906] 431 [RFC2257] 432 [IPv6] 433 [IANA-CONSIDERATIONS] 435 11. Security Considerations 437 This MIB module defines assigned values for commonly used addressing 438 domains, and a set of textual conventions. It does not define any 439 MIB objects that actually contain management information. 441 As such, there are no security considerations for this module. 443 12. Author's Address 445 Mike Daniele 446 Compaq Computer Corporation 447 110 Spit Brook Rd 448 Nashua, NH 03062 450 Phone: +1-603-884-1423 451 EMail: daniele@zk3.dec.com 453 13. Full Copyright Statement 455 Copyright (C) The Internet Society (1998). All Rights Reserved. 457 This document and translations of it may be copied and furnished to 458 others, and derivative works that comment on or otherwise explain it 459 or assist in its implementation may be prepared, copied, published 460 and distributed, in whole or in part, without restriction of any 461 kind, provided that the above copyright notice and this paragraph are 462 included on all such copies and derivative works. However, this 463 document itself may not be modified in any way, such as by removing 464 the copyright notice or references to the Internet Society or other 465 Internet organizations, except as needed for the purpose of 466 developing Internet standards in which case the procedures for 467 copyrights defined in the Internet Standards process must be 468 followed, or as required to translate it into languages other than 469 English. 471 The limited permissions granted above are perpetual and will not be 472 revoked by the Internet Society or its successors or assigns. 474 This document and the information contained herein is provided on an 475 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 476 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 477 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 478 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 479 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 481 Expires March, 1999