smilint output for ./INET-ADDRESS-MIB

Messages:

INET-ADDRESS-MIB

   1: -- extracted from rfc4001.txt
   2: -- at Wed Feb 23 06:25:09 2005

  53: 
  54: InetAddressType ::= TEXTUAL-CONVENTION

  55:     STATUS      current
  56:     DESCRIPTION
  57:         "A value that represents a type of Internet address.
  58: 
  59:          unknown(0)  An unknown address type.  This value MUST
  60:                      be used if the value of the corresponding
  61:                      InetAddress object is a zero-length string.
  62:                      It may also be used to indicate an IP address
  63:                      that is not in one of the formats defined
  64:                      below.
  65: 
  66:          ipv4(1)     An IPv4 address as defined by the
  67:                      InetAddressIPv4 textual convention.
  68: 
  69:          ipv6(2)     An IPv6 address as defined by the
  70:                      InetAddressIPv6 textual convention.
  71: 
  72:          ipv4z(3)    A non-global IPv4 address including a zone
  73:                      index as defined by the InetAddressIPv4z
  74:                      textual convention.
  75: 
  76:          ipv6z(4)    A non-global IPv6 address including a zone
  77:                      index as defined by the InetAddressIPv6z
  78:                      textual convention.
  79: 
  80:          dns(16)     A DNS domain name as defined by the
  81:                      InetAddressDNS textual convention.
  82: 
  83:          Each definition of a concrete InetAddressType value must be
  84:          accompanied by a definition of a textual convention for use
  85:          with that InetAddressType.
  86: 
  87:          To support future extensions, the InetAddressType textual
  88:          convention SHOULD NOT be sub-typed in object type definitions.
  89:          It MAY be sub-typed in compliance statements in order to
  90:          require only a subset of these address types for a compliant
  91:          implementation.
  92: 
  93:          Implementations must ensure that InetAddressType objects
  94:          and any dependent objects (e.g., InetAddress objects) are
  95:          consistent.  An inconsistentValue error must be generated
  96:          if an attempt to change an InetAddressType object would,
  97:          for example, lead to an undefined InetAddress value.  In
  98:          particular, InetAddressType/InetAddress pairs must be
  99:          changed together if the address type changes (e.g., from
 100:          ipv6(2) to ipv4(1))."
 101:     SYNTAX       INTEGER {
 102:                      unknown(0),
 103:                      ipv4(1),
 104:                      ipv6(2),
 105:                      ipv4z(3),
 106:                      ipv6z(4),
 107:                      dns(16)
 108:                  }
 109: 
 110: InetAddress ::= TEXTUAL-CONVENTION

 111:     STATUS      current
 112:     DESCRIPTION
 113:         "Denotes a generic Internet address.
 114: 
 115:          An InetAddress value is always interpreted within the context
 116:          of an InetAddressType value.  Every usage of the InetAddress
 117:          textual convention is required to specify the InetAddressType
 118:          object that provides the context.  It is suggested that the
 119:          InetAddressType object be logically registered before the
 120:          object(s) that use the InetAddress textual convention, if
 121:          they appear in the same logical row.
 122: 
 123:          The value of an InetAddress object must always be
 124:          consistent with the value of the associated InetAddressType
 125:          object.  Attempts to set an InetAddress object to a value
 126:          inconsistent with the associated InetAddressType
 127:          must fail with an inconsistentValue error.
 128: 
 129:          When this textual convention is used as the syntax of an
 130:          index object, there may be issues with the limit of 128
 131:          sub-identifiers specified in SMIv2, STD 58.  In this case,
 132:          the object definition MUST include a 'SIZE' clause to
 133:          limit the number of potential instance sub-identifiers;
 134:          otherwise the applicable constraints MUST be stated in
 135:          the appropriate conceptual row DESCRIPTION clauses, or
 136:          in the surrounding documentation if there is no single
 137:          DESCRIPTION clause that is appropriate."
 138:     SYNTAX       OCTET STRING (SIZE (0..255))
 139: 
 140: InetAddressIPv4 ::= TEXTUAL-CONVENTION

 141:     DISPLAY-HINT "1d.1d.1d.1d"
 142:     STATUS       current
 143:     DESCRIPTION
 144:         "Represents an IPv4 network address:
 145:            Octets   Contents         Encoding
 146:             1-4     IPv4 address     network-byte order
 147: 
 148:          The corresponding InetAddressType value is ipv4(1).
 149: 
 150:          This textual convention SHOULD NOT be used directly in object
 151:          definitions, as it restricts addresses to a specific format.
 152:          However, if it is used, it MAY be used either on its own or in
 153:          conjunction with InetAddressType, as a pair."
 154:     SYNTAX       OCTET STRING (SIZE (4))
 155: 
 156: InetAddressIPv6 ::= TEXTUAL-CONVENTION

 157:     DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x"
 158:     STATUS       current
 159:     DESCRIPTION
 160:         "Represents an IPv6 network address:
 161: 
 162:            Octets   Contents         Encoding
 163:             1-16    IPv6 address     network-byte order
 164: 
 165:          The corresponding InetAddressType value is ipv6(2).
 166: 
 167:          This textual convention SHOULD NOT be used directly in object
 168:          definitions, as it restricts addresses to a specific format.
 169:          However, if it is used, it MAY be used either on its own or in
 170:          conjunction with InetAddressType, as a pair."
 171:     SYNTAX       OCTET STRING (SIZE (16))
 172: 
 173: InetAddressIPv4z ::= TEXTUAL-CONVENTION

 174:     DISPLAY-HINT "1d.1d.1d.1d%4d"
 175:     STATUS       current
 176:     DESCRIPTION
 177:         "Represents a non-global IPv4 network address, together
 178:          with its zone index:
 179: 
 180:            Octets   Contents         Encoding
 181:             1-4     IPv4 address     network-byte order
 182:             5-8     zone index       network-byte order
 183: 
 184:          The corresponding InetAddressType value is ipv4z(3).
 185: 
 186:          The zone index (bytes 5-8) is used to disambiguate identical
 187:          address values on nodes that have interfaces attached to
 188:          different zones of the same scope.  The zone index may contain
 189:          the special value 0, which refers to the default zone for each
 190:          scope.
 191: 
 192:          This textual convention SHOULD NOT be used directly in object
 193:          definitions, as it restricts addresses to a specific format.
 194:          However, if it is used, it MAY be used either on its own or in
 195:          conjunction with InetAddressType, as a pair."
 196:     SYNTAX       OCTET STRING (SIZE (8))
 197: 
 198: InetAddressIPv6z ::= TEXTUAL-CONVENTION

 199:     DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d"
 200:     STATUS       current
 201:     DESCRIPTION
 202:         "Represents a non-global IPv6 network address, together
 203:          with its zone index:
 204: 
 205:            Octets   Contents         Encoding
 206:             1-16    IPv6 address     network-byte order
 207:            17-20    zone index       network-byte order
 208: 
 209:          The corresponding InetAddressType value is ipv6z(4).
 210: 
 211:          The zone index (bytes 17-20) is used to disambiguate
 212:          identical address values on nodes that have interfaces
 213:          attached to different zones of the same scope.  The zone index
 214:          may contain the special value 0, which refers to the default
 215:          zone for each scope.
 216: 
 217:          This textual convention SHOULD NOT be used directly in object
 218:          definitions, as it restricts addresses to a specific format.
 219:          However, if it is used, it MAY be used either on its own or in
 220:          conjunction with InetAddressType, as a pair."
 221:     SYNTAX       OCTET STRING (SIZE (20))
 222: 
 223: InetAddressDNS ::= TEXTUAL-CONVENTION

 224:     DISPLAY-HINT "255a"
 225:     STATUS       current
 226:     DESCRIPTION
 227:         "Represents a DNS domain name.  The name SHOULD be fully
 228:          qualified whenever possible.
 229: 
 230:          The corresponding InetAddressType is dns(16).
 231: 
 232:          The DESCRIPTION clause of InetAddress objects that may have
 233:          InetAddressDNS values MUST fully describe how (and when)
 234:          these names are to be resolved to IP addresses.
 235: 
 236:          The resolution of an InetAddressDNS value may require to
 237:          query multiple DNS records (e.g., A for IPv4 and AAAA for
 238:          IPv6).  The order of the resolution process and which DNS
 239:          record takes precedence depends on the configuration of the
 240:          resolver.
 241:          This textual convention SHOULD NOT be used directly in object
 242:          definitions, as it restricts addresses to a specific format.
 243:          However, if it is used, it MAY be used either on its own or in
 244:          conjunction with InetAddressType, as a pair."
 245:     SYNTAX       OCTET STRING (SIZE (1..255))
 246: 
 247: InetAddressPrefixLength ::= TEXTUAL-CONVENTION

 248:     DISPLAY-HINT "d"
 249:     STATUS       current
 250:     DESCRIPTION
 251:         "Denotes the length of a generic Internet network address
 252:          prefix.  A value of n corresponds to an IP address mask
 253:          that has n contiguous 1-bits from the most significant
 254:          bit (MSB), with all other bits set to 0.
 255: 
 256:          An InetAddressPrefixLength value is always interpreted within
 257:          the context of an InetAddressType value.  Every usage of the
 258:          InetAddressPrefixLength textual convention is required to
 259:          specify the InetAddressType object that provides the
 260:          context.  It is suggested that the InetAddressType object be
 261:          logically registered before the object(s) that use the
 262:          InetAddressPrefixLength textual convention, if they appear
 263:          in the same logical row.
 264: 
 265:          InetAddressPrefixLength values larger than
 266:          the maximum length of an IP address for a specific
 267:          InetAddressType are treated as the maximum significant
 268:          value applicable for the InetAddressType.  The maximum
 269:          significant value is 32 for the InetAddressType
 270:          'ipv4(1)' and 'ipv4z(3)' and 128 for the InetAddressType
 271:          'ipv6(2)' and 'ipv6z(4)'.  The maximum significant value
 272:          for the InetAddressType 'dns(16)' is 0.
 273: 
 274:          The value zero is object-specific and must be defined as
 275:          part of the description of any object that uses this
 276:          syntax.  Examples of the usage of zero might include
 277:          situations where the Internet network address prefix
 278:          is unknown or does not apply.
 279: 
 280:          The upper bound of the prefix length has been chosen to
 281:          be consistent with the maximum size of an InetAddress."
 282:     SYNTAX       Unsigned32 (0..2040)
 283: 
 284: InetPortNumber ::= TEXTUAL-CONVENTION

 285:     DISPLAY-HINT "d"
 286:     STATUS       current
 287:     DESCRIPTION
 288:         "Represents a 16 bit port number of an Internet transport
 289:          layer protocol.  Port numbers are assigned by IANA.  A
 290:          current list of all assignments is available from
 291:          <http://www.iana.org/>.
 292: 
 293:          The value zero is object-specific and must be defined as
 294:          part of the description of any object that uses this
 295:          syntax.  Examples of the usage of zero might include
 296:          situations where a port number is unknown, or when the
 297:          value zero is used as a wildcard in a filter."
 298:     REFERENCE   "STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960"
 299:     SYNTAX       Unsigned32 (0..65535)
 300: 
 301: InetAutonomousSystemNumber ::= TEXTUAL-CONVENTION

 302:     DISPLAY-HINT "d"
 303:     STATUS       current
 304:     DESCRIPTION
 305:         "Represents an autonomous system number that identifies an
 306:          Autonomous System (AS).  An AS is a set of routers under a
 307:          single technical administration, using an interior gateway
 308:          protocol and common metrics to route packets within the AS,
 309:          and using an exterior gateway protocol to route packets to
 310:          other ASes'.  IANA maintains the AS number space and has
 311:          delegated large parts to the regional registries.
 312: 
 313:          Autonomous system numbers are currently limited to 16 bits
 314:          (0..65535).  There is, however, work in progress to enlarge the
 315:          autonomous system number space to 32 bits.  Therefore, this
 316:          textual convention uses an Unsigned32 value without a
 317:          range restriction in order to support a larger autonomous
 318:          system number space."
 319:     REFERENCE   "RFC 1771, RFC 1930"
 320:     SYNTAX       Unsigned32
 321: 
 322: InetScopeType ::= TEXTUAL-CONVENTION

 323:     STATUS       current
 324:     DESCRIPTION
 325:         "Represents a scope type.  This textual convention can be used
 326:          in cases where a MIB has to represent different scope types
 327:          and there is no context information, such as an InetAddress
 328:          object, that implicitly defines the scope type.
 329: 
 330:          Note that not all possible values have been assigned yet, but
 331:          they may be assigned in future revisions of this specification.
 332:          Applications should therefore be able to deal with values
 333:          not yet assigned."
 334:     REFERENCE   "RFC 3513"
 335:     SYNTAX       INTEGER {
 336:                      -- reserved(0),
 337:                      interfaceLocal(1),
 338:                      linkLocal(2),
 339:                      subnetLocal(3),
 340:                      adminLocal(4),
 341:                      siteLocal(5), -- site-local unicast addresses
 342:                                    -- have been deprecated by RFC 3879
 343:                      -- unassigned(6),
 344:                      -- unassigned(7),
 345:                      organizationLocal(8),
 346:                      -- unassigned(9),
 347:                      -- unassigned(10),
 348:                      -- unassigned(11),
 349:                      -- unassigned(12),
 350:                      -- unassigned(13),
 351:                      global(14)
 352:                      -- reserved(15)
 353:                  }
 354: 
 355: InetZoneIndex ::= TEXTUAL-CONVENTION

 356:     DISPLAY-HINT "d"
 357:     STATUS       current
 358:     DESCRIPTION
 359:         "A zone index identifies an instance of a zone of a
 360:          specific scope.
 361: 
 362:          The zone index MUST disambiguate identical address
 363:          values.  For link-local addresses, the zone index will
 364:          typically be the interface index (ifIndex as defined in the
 365:          IF-MIB) of the interface on which the address is configured.
 366: 
 367:          The zone index may contain the special value 0, which refers
 368:          to the default zone.  The default zone may be used in cases
 369:          where the valid zone index is not known (e.g., when a
 370:          management application has to write a link-local IPv6
 371:          address without knowing the interface index value).  The
 372:          default zone SHOULD NOT be used as an easy way out in
 373:          cases where the zone index for a non-global IPv6 address
 374:          is known."
 375:     REFERENCE   "RFC4007"
 376:     SYNTAX       Unsigned32
 377: 
 378: InetVersion ::= TEXTUAL-CONVENTION

 379:     STATUS  current
 380:     DESCRIPTION
 381:         "A value representing a version of the IP protocol.
 382: 
 383:          unknown(0)  An unknown or unspecified version of the IP
 384:                      protocol.
 385: 
 386:          ipv4(1)     The IPv4 protocol as defined in RFC 791 (STD 5).
 387: 
 388:          ipv6(2)     The IPv6 protocol as defined in RFC 2460.
 389: 
 390:          Note that this textual convention SHOULD NOT be used to
 391:          distinguish different address types associated with IP
 392:          protocols.  The InetAddressType has been designed for this
 393:          purpose."
 394:     REFERENCE   "RFC 791, RFC 2460"
 395:     SYNTAX       INTEGER {
 396:                      unknown(0),
 397:                      ipv4(1),
 398:                      ipv6(2)
 399:                  }
 400: END
 401: 
 402: -- 
 403: --    Copyright (C) The Internet Society (2005).
 404: -- 
 405: --    This document is subject to the rights, licenses and restrictions
 406: --    contained in BCP 78, and at www.rfc-editor.org, and except as set
 407: --    forth therein, the authors retain all their rights.
 408: -- 
 409: --    This document and the information contained herein are provided on an
 410: --    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 411: --    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 412: --    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 413: --    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 414: --    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 415: --    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 416: -- 
 417: -- Intellectual Property
 418: -- 
 419: --    The IETF takes no position regarding the validity or scope of any
 420: --    Intellectual Property Rights or other rights that might be claimed to
 421: --    pertain to the implementation or use of the technology described in
 422: --    this document or the extent to which any license under such rights
 423: --    might or might not be available; nor does it represent that it has
 424: --    made any independent effort to identify any such rights.  Information
 425: --    on the ISOC's procedures with respect to rights in ISOC Documents can
 426: --    be found in BCP 78 and BCP 79.
 427: -- 
 428: --    Copies of IPR disclosures made to the IETF Secretariat and any
 429: --    assurances of licenses to be made available, or the result of an
 430: --    attempt made to obtain a general license or permission for the use of
 431: --    such proprietary rights by implementers or users of this
 432: --    specification can be obtained from the IETF on-line IPR repository at
 433: --    http://www.ietf.org/ipr.
 434: -- 
 435: --    The IETF invites any interested party to bring to its attention any
 436: --    copyrights, patents or patent applications, or other proprietary
 437: --    rights that may cover technology that may be required to implement
 438: --    this standard.  Please address the information to the IETF at ietf-
 439: --    ipr@ietf.org.
 440: -- 
 441: