How to use TransportAddressIPv4 in conjunction with TransportAddressType as a pair?

MIB Designer
1

With my limited knowledge of SNMP MIB constructs and such, I kindly ask for help in understanding how to approach my problem.

I have today a working solution for configuring an IPv4 address and Port in one object using this:

TransportAddressIPv4 ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1d.1d.1d.1d:2d"
    STATUS      current
    DESCRIPTION
        "Represents a transport address consisting of an IPv4
         address and a port number (as used for example by UDP,
         TCP and SCTP):

          octets       contents         encoding
           1-4         IPv4 address     network-byte order
           5-6         port number      network-byte order

         This textual convention SHOULD NOT be used directly in object
         definitions since it restricts addresses to a specific format.
         However, if it is used, it MAY be used either on its own or
         **in conjunction with TransportAddressType** or TransportDomain
         **as a pair.**"
    SYNTAX      OCTET STRING (SIZE (6))

Now I need to extend this object to also include IPv6 and Dns as choices and the description of TransportAddressIPv4 implies that there should be a way to combine it with TransportAddressType as a pair. How would that be done? I can’t find anything in any RFC nor elsewhere that does this.

Some clarification; I have this object, which is limited to IPv4 addresses.

myAddress OBJECT-TYPE
    SYNTAX      TransportAddressIPv4
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "IPv4 address and Port.
        "
    ::= { myObject 2 }

…and now I’d like to replace TransportAddressIPv4 in this object with a pair, using TransportAddressType in some way. I suppose that it would be going together with the general definition TransportAddress (I also don’t know how to do that), but how could I also include the specific TransportAddressIPv4, TransportAddressIPv6 and TransportAddressDns as choices in order to benefit from e.g. the DISPLAY-HINTs in those TEXTUAL-CONVENTIONs?

bmk

11d

Unfortunately compilation of the SEQUENCE example fails:

% rebar3 compile              
===> Verifying dependencies...
===> Analyzing applications...
MY-MIB.mib: 709: Undefined type ''MyTransport''
[MY-MIB.mib:731][WAR]: Unexpected SEQUENCE 'MyTransport' => ignoring

I suppose I could use that construction if I just can get it to compile, but in any case I’d prefer a solution using CHOICE. I have also not been able to find any examples with the CHOICE construct. Anyone…?

2

Please check the TRANSPORT-ADDRESS-MIB (see RFC 3419, RFC 3419 - Textual Conventions for Transport Addresses) and use its standard OIDs and textual conventions to accomplish your task and IMPORT that module to your MIB module.

Additional hint: For SNMP, the language “Structure of Management Information v2” (SMIv2) must be used which is well defined and not ASN.1 (in fact it is a subset with a defined set of MACRO definitions). Thus, you must not use ASN.1 free style constructs to extend SMI with your own data structures - that will not work on the wire.

3

A simple sample (indirect) usage of the TRANSPORT-ADDRESS-MIB is the SNMP-TARGET-MIB (it uses an “old” variant but still compatible):

snmpTargetAddrTDomain OBJECT-TYPE
        SYNTAX  TDomain
        MAX-ACCESS read-create
        STATUS  current
        DESCRIPTION
                "This object indicates the transport type of the address
                contained in the snmpTargetAddrTAddress object."
        -- 1.3.6.1.6.3.12.1.2.1.2
        ::= { snmpTargetAddrEntry 2 }

snmpTargetAddrTAddress OBJECT-TYPE
        SYNTAX  TAddress
        MAX-ACCESS read-create
        STATUS  current
        DESCRIPTION
                "This object contains a transport address.  The format of
                this address depends on the value of the
                snmpTargetAddrTDomain object."
        -- 1.3.6.1.6.3.12.1.2.1.3
        ::= { snmpTargetAddrEntry 3 }

You can still use TDomain and TAddress textual conventions, but directly using the TransportDomain and TransportAddress would be fine too.