Subject: [MIB-DOCTORS] Compilation of RFC 5060 PIM MIB

From: "Noam Brousard" <[email-masked]>
Date: Wed, 25 Jan 2012 10:32:12 +0200

Hi Doctors,

I tried compiling the latest PIM MIB (RFC 5060) and got the following
error:

A named number list may be applied only to the INTEGER type itself, and
not to a type derived from the INTEGER type for SYNTAX declarations such
as the following:

pimStarGPimMode OBJECT-TYPE

    SYNTAX     PimMode { asm(3), bidir(4) }

    MAX-ACCESS read-only

    STATUS     current

    DESCRIPTION

            "Whether this entry represents an ASM (Any Source Multicast,

            used with PIM-SM) or BIDIR-PIM group."

    ::= { pimStarGEntry 4 } 

Where PimMode was previously defined as: 

PimMode ::= TEXTUAL-CONVENTION

    STATUS     current

    DESCRIPTION

            "The PIM mode in which a group is operating.

            none(1)      The group is not using PIM, which may be the

                         case if, for example, it is a link-local or

                         unroutable group address.

            ssm(2)       Source-Specific Multicast (SSM) with PIM Sparse

                         Mode.

            asm(3)       Any Source Multicast (ASM) with PIM Sparse

                         Mode.

            bidir(4)     Bidirectional PIM.

            dm(5)        PIM Dense Mode.

            other(6)     Any other PIM mode."

    SYNTAX     INTEGER {

                  none(1),

                  ssm(2),

                  asm(3),

                  bidir(4),

                  dm(5),

                  other(6)

               }

Can you shed any light on this issue? Is it just a matter of tweaking my
compiler?

Thanks,

Noam

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Jan 2012 17:47:35 +0100

>             used with PIM-SM) or BIDIR-PIM group."

The subtyping of enumerated INTEGER TCs enjoys quite some usage in
conformance statements (in particular InetAddressType and RowStatus
and StorageType come to my mind). Such subtyping is less frequently
used in object type definitions.

> Can you shed any light on this issue? Is it just a matter of tweaking my

Does your compiler allow TC subtyping in OBJECT definition in
compliance statements? For example, the TUNNEL-MIB [RFC4087] has:

        OBJECT      tunnelIfAddressType
        SYNTAX      InetAddressType { ipv4(1), ipv6(2),
                                      ipv4z(3), ipv6z(4) }

Section 11 of RFC 2578 really only talks about range and size
subtyping. RFC 2579 just says this:

   The SYNTAX clause of a TEXTUAL CONVENTION macro may be sub-typed in
   the same way as the SYNTAX clause of an OBJECT-TYPE macro (see
   section 11 of [2]).

But then, it seems common practice that we do allow named number
INTEGER subtyping.

/js

PS: For the SMIv2 geeks: The hidden issue here is that it is allowed
    to change the label associated with a number when a module is
    revised. This can break named number subtyping in modules that
    import a named number TC. Hence, changing a label or removing a
    named number is really really a bad idea.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 25 Jan 2012 10:44:34 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Noam Brousard" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, January 25, 2012 8:47 AM
> Subject: Re: [MIB-DOCTORS] Compilation of RFC 5060 PIM MIB
...
> But then, it seems common practice that we do allow named number

The practice seems reasonable to me.  After all, RFC 2578 does say:

   An extended subset of the full capabilities of ASN.1 (1988) sub-
   typing is allowed, as appropriate to the underlying ASN.1 type. 

Randy