idnits 2.17.1 draft-ops-endpoint-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 419 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 18 instances of too long lines in the document, the longest one being 16 characters in excess of 72. ** There are 88 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 114 has weird spacing: '... octets cont...' == Line 130 has weird spacing: '... octets cont...' == Line 131 has weird spacing: '...address net...' -- 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 1999) is 9021 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) -- Missing reference section? 'SMIv2' on line 92 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Endpoint MIB August 1999 2 Expires February, 2000 4 Internet Endpoint MIB 6 8 1. Status of this Memo 10 This document is an Internet-Draft and is in full conformance 11 with all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 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 The list of current Internet-Drafts can be accessed at^M 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 2. Abstract 32 This MIB module defines constructs to represent commonly used 33 addressing information. The intent is that these definitions 34 will be imported and used in the various MIBs that would otherwise 35 define their own representations. This work is output from the 36 Operations and Management Area "IPv6MIB" design team. 38 3. Definitions 40 INET-ENDPOINT-MIB DEFINITIONS ::= BEGIN 42 IMPORTS 43 MODULE-IDENTITY FROM SNMPv2-SMI 44 TEXTUAL-CONVENTION FROM SNMPv2-TC; 46 inetEndpointMIB MODULE-IDENTITY 47 LAST-UPDATED "9907300000Z" 48 ORGANIZATION "IETF OPS Area" 49 CONTACT-INFO "Send comments to mibs@ops.ietf.org" 50 DESCRIPTION 51 "A MIB module for Internet address definitions." 52 ::= { TBD } 54 -- 55 -- 56 -- New TCs for representing generic Internet endpoints. 57 -- These are roughly equivalent to TDomain and TAddress... 58 -- 59 -- 61 -- 62 -- Internet endpoints types 63 -- 64 InetEndpointType ::= TEXTUAL-CONVENTION 65 STATUS current 66 DESCRIPTION 67 "A value that represents a type of Internet endpoint. 69 Note that it is possible to sub-type objects defined with 70 this syntax by removing one or more enumerated values. 71 The DESCRIPTION clause of such objects (or their corresponding 72 InetEndpoint object) must document specific usage." 73 SYNTAX INTEGER { 74 other(0), 75 ipv4(1), 76 ipv6(2), 77 dns(3) 78 } 80 InetEndpoint ::= TEXTUAL-CONVENTION 81 STATUS current 82 DESCRIPTION 83 "Denotes an generic Internet endpoint. 85 A InetEndpoint value is always interpreted within the context of a 86 InetEndpointType value. Thus, each definition of a InetEndpointType 87 value must be accompanied by a definition of a textual convention 88 for use with that InetEndpointType. 90 When this Textual Convention is used as the syntax of an index object, 91 there may be issues with the limit of 128 sub-identifiers specified 92 in [SMIv2]. In this case, it is recommended that the OBJECT-TYPE 93 declaration include a "SIZE" clause to limit the number of potential 94 instance sub-identifiers. 95 REFERENCE "See the TAddress TC in std58." 96 SYNTAX OCTET STRING (SIZE (0..255)) 98 -- 99 -- 100 -- TCs for specific Internet endpoint values. 101 -- 102 -- 104 -- 105 -- IPv4 Address 106 -- 108 InetEndpointIPv4 ::= TEXTUAL-CONVENTION 109 DISPLAY-HINT "1d.1d.1d.1d" 110 STATUS current 111 DESCRIPTION 112 "Represents an IPv4 network address: 114 octets contents encoding 115 1-4 IP address network-byte order 117 The corresponding InetEndpointType is ipv4(1)." 118 SYNTAX OCTET STRING (SIZE (4)) 120 -- 121 -- IPv6 Address 122 -- 124 InetEndpointIPv6 ::= TEXTUAL-CONVENTION 125 DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x" 126 STATUS current 127 DESCRIPTION 128 "Represents an IPv6 network address: 130 octets contents encoding 131 1-16 IPv6 address network-byte order 133 The corresponding InetEndpointType is ipv6(2)." 134 REFERENCE "See the Ipv6Address TC in RFC 2465." 135 SYNTAX OCTET STRING (SIZE (16)) 137 -- 138 -- DNS Name 139 -- 141 InetEndpointDNS ::= TEXTUAL-CONVENTION 142 DISPLAY-HINT "255a" 143 STATUS current 144 DESCRIPTION 145 "Represents a fully qualified DNS host name. 146 The corresponding InetEndpointType is dns(3). 148 The DESCRIPTION clause of InetEndpoint objects that 149 may have InetEndpointDNS values must fully describe 150 how (and when) such names are to be resolved to IP 151 addresses." 152 REFERENCE "RFCs 952 and 1123." 153 SYNTAX OCTET STRING (SIZE (1..255)) 155 END 157 4. Usage 159 These definitions provide a mechanism to define generic 160 Internet-accessible endpoints within MIB specifications. 161 It is recommended that MIB developers use these definitions 162 when applicable, as opposed to defining their own constructs. 164 A generic Internet endpoint consists of two objects, 165 one whose syntax is InetEndpointType, and another whose 166 syntax is InetEndpoint. The value of the first object 167 determines how the value of the second object is encoded. 169 One particular usage of InetEndpointType/InetEndpoint pairs 170 is to avoid over-constraining an object definition by the 171 use of the IpAddress syntax. IpAddress limits an implementation 172 to using IPv4 addresses only, and as such should only be used 173 when the object truly is IPv4-specific. 175 5. Indexing 177 When a generic Internet endpoint is used as an index, both 178 the InetEndpointType and InetEndpoint objects must be used, and 179 the InetEndpointType object must come first in the INDEX clause. 181 Instance subidentifiers are then of the form T.N.O1.O2...On, 182 where T is the value of the InetEndpointType object, O1...On 183 are the octets in the InetEndpoint object, and N is the number 184 of those octets. 186 There is a meaningful lexicographical ordering to tables indexed 187 in this fashion. Command generator applications may 189 o lookup specific endpoints of known type and value 190 o issue GetNext requests for endpoints of a single type 191 o issue GetNext requests for specific type and address prefix 193 It should be pointed out that another valid approach is to 194 define separate tables for different address types. For example, 195 one table might be indexed by an IpAddress object, and the other 196 table indexed by an Ipv6Address object. This is a decision for the 197 MIB designer. (For example, the tcpConnTable was left intact and a new 198 table added for TCP connections over IPv6, see RFC 2452.) 200 6. Uniqueness of Addresses 202 IPv4 addresses were intended to be globally unique, current 203 usage notwithstanding. IPv6 addresses were architected to 204 have different scopes and hence uniqueness. In particular, 205 IPv6 "link-local" and "site-local" addresses are not guaranteed 206 to be unique on any particular node. In such cases, the duplicate 207 addresses must be configured on different interfaces, so the combination 208 of IPv6 address/interface is unique. 210 For tables indexed by InetEndpointType/InetEndpoint pairs, where 211 there may be non-unique instances of InetEndpointIPv6, the recommended 212 approach is to add a third index object to ensure uniqueness. 214 It is recommended that the syntax of this third index object be 215 InterfaceIndexOrZero, from IF-MIB. The value of this object 216 should be 0 when the value of the InetEndpointType object is 217 not ipv6(2). 219 << TBD: what about Ipv6IfIndexOrZero in RFC 2465? >> 221 7. Multiple InetEndpoints per Host 223 Note that a single host system may be configured with multiple 224 addresses (IPv4 or IPv6), and possibly with multiple DNS names. 225 Thus it is possible for a single host system to be represented 226 by multiple (unique) InetEndpointType/InetEndpoint pairs. 228 If this could be an implementation or usage issue the DESCRIPTION 229 clause of the relevant objects should fully describe required 230 behavior. 232 8. Resolving DNS Names 234 DNS names are translated to IP addresses when communication with 235 a host is required. This raises a temporal aspect to defining MIB 236 objects whose value is a DNS name; when is the name translated to 237 an address? 239 For example, consider an object defined to indicate a forwarding 240 destination, and whose value is a DNS name. When does the 241 forwarding entity resolve the DNS name? Each time forwarding occurs? 242 Once, when the object was instantiated? 244 The DESCRIPTION clause of such objects should precisely define 245 how (when) any required name to address resolution is done. 247 9. Usage Examples 249 Example 1: 251 fooTable OBJECT-TYPE 252 SYNTAX SEQUENCE OF FooEntry 253 MAX-ACCESS not-accessible 254 STATUS current 255 DESCRIPTION 256 "The foo table." 257 ::= { bar 1 } 259 fooEntry OBJECT-TYPE 260 SYNTAX FooEntry 261 MAX-ACCESS not-accessible 262 STATUS current 263 DESCRIPTION 264 "A foo entry." 265 INDEX { fooPartnerType, fooPartner } 266 ::= { fooTable 1 } 268 FooEntry ::= SEQUENCE { 269 fooPartnerType InetEndpointType, 270 fooPartner InetEndpoint, 271 fooStatus INTEGER, 272 fooDescr OCTET STRING 273 } 275 fooPartnerType ::= OBJECT-TYPE 276 SYNTAX InetEndpointType 277 MAX-ACCESS not-accessible 278 STATUS current 279 DESCRIPTION 280 "The type of Internet endpoint by which the partner is reachable." 281 ::= { fooEntry 1 } 283 fooPartner ::= OBJECT-TYPE 284 SYNTAX InetEndpoint (SIZE (0..64)) 285 MAX-ACCESS not-accessible 286 STATUS current 287 DESCRIPTION 288 "The Internet endpoint for the partner. Note that implementations 289 must limit themselves to a single entry in this table per reachable 290 partner. Also, if an Ipv6 endpoint is used, it must contain a globally 291 unique IPv6 address." 292 ::= { fooEntry 2 } 294 Example 2: 296 sysAddrTable OBJECT-TYPE 297 SYNTAX SEQUENCE OF SysAddrEntry 298 MAX-ACCESS not-accessible 299 STATUS current 300 DESCRIPTION 301 "The sysAddr table." 302 ::= { sysAddr 1 } 304 sysAddrEntry OBJECT-TYPE 305 SYNTAX SysAddrEntry 306 MAX-ACCESS not-accessible 307 STATUS current 308 DESCRIPTION 309 "A sysAddr entry." 310 INDEX { sysAddrType, sysAddr, sysAddrIfIndex } 311 ::= { sysAddrTable 1 } 313 SysAddrEntry ::= SEQUENCE { 314 sysAddrPartnerType InetEndpointType, 315 sysAddrPartner InetEndpoint, 316 sysAddrIfIndex InterfaceIndexOrZero, 317 sysAddrStatus INTEGER, 318 sysAddrDescr OCTET STRING 319 } 321 sysAddrType ::= OBJECT-TYPE 322 SYNTAX InetEndpointType { 323 ipv4(1), 324 ipv6(2) 325 } 326 MAX-ACCESS not-accessible 327 STATUS current 328 DESCRIPTION 329 "The type of system address." 330 ::= { sysAddrEntry 1 } 332 sysAddr ::= OBJECT-TYPE 333 SYNTAX InetEndpoint (SIZE (4 | 16)) 334 MAX-ACCESS not-accessible 335 STATUS current 336 DESCRIPTION 337 "The system address." 338 ::= { sysAddrEntry 2 } 340 sysAddrIfIndex ::= OBJECT-TYPE 341 SYNTAX InterfaceIndexOrZero 342 MAX-ACCESS not-accessible 343 STATUS current 344 DESCRIPTION 345 "The system address interface. This object is used to disambiguate 346 duplicate system IPv6 addresses, and should be 0 for non-duplicate 347 addresses." 348 ::= { sysAddrEntry 3 } 350 10. References 352 TBD 354 11. Copyright 356 TBD 358 12. Authors 360 This work was done by the IETF Ops Area "IPv6MIB" Design Team. 361 Comments should be posted to mibs@ops.ietf.org. 363 Appendix 365 This appendix lists the issues raised over common addressing 366 MIB constructs, and the reasoning for the decisions made in 367 this module. 369 1. Efficient table lookups 371 Some existing MIBs have tables of generic addresses, indexed 372 by a random integer. This makes it impossible to lookup 373 specific addresses, or issue meaningful GetNext operations. 375 2. Common addressing should be defined such that no SMI changes 376 are required. 378 For example, the use of the ASN.1 CHOICE would really be an SMI 379 change. 381 3. TCs and DISPLAY-HINTS 383 A single object that contains both address type and value 384 does not provide a way to express the display characteristics 385 of each type. 387 (Also, such a single object requires code changes to handle updates, 388 whereas the solution chosen requires only MIB updates.) 390 4. Document the possible non-uniqueness of IPv6 addresses, and the 391 impact on indexing tables. 393 5. TDomain/TAddress limited to transport services 395 It was unclear if network layer addresses were appropriate 396 for use in TAddress values, since std58 refers specifically to 397 "transport addresses". 399 This point is less important than std58's definition that 400 TAddress values always be defined in the context of TDomain 401 values. Since did not want to index by OIDs, we did not 402 use TDomain and hence cannot use TAddress. 404 6. Harness the use of IpAddress 406 Several standard-track MIBs have used IpAddress syntax 407 inadvertently, needlessly limiting implementations to IPv4. 409 The specification under development should address this. 411 7. DNS names in addition to addresses 413 It is useful to be able to specify a system via a DNS name, 414 so the common addressing mechanism should support them. 416 Expires February, 2000