Subject: [netmod] smi2yang-01: ambiguity of OID descriptors (container nesting)

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Apr 2011 12:01:30 +0200

* smi2yang-01: ambiguity of OID descriptors (container nesting)

  Producing containers of OID value assignments is difficult since
  multiple descriptors may refer to the same OID value:

    foo OBJECT IDENTIFIER ::= { baz 1 }
    bar OBJECT IDENTIFIER ::= { baz 1 } 

  Simple rules like choosing the first defined descriptor do not work
  either since OID value assignments may be reordered in SMIv2 modules
  and new ones can be added.

** Solution #01-01:

   - Drop the idea to represent the OID tree hierarchy by means of
     nested YANG containers. Instead, do the following:
     
     o Generate a top-level container named after the MODULE-IDENTITY
       node and put _all_ scalars into this container.
     
     o Translate all regular tables into top-level container named
       after the *Table node. The table container contains a list named
       after the *Entry node.

     o Translate all augmenting tables, that is the augmenting *Entry
       nodes, into top-level augment statements (dropping the *Table
       nodes).

   - This solution results in a flat schema structure and it avoids
     using OID descriptors, thus the problem is solved.

   - If OID tree information is desirable to be captured in the
     generated YANG module, we could have extension statements to
     represent the OID structure, e.g.:

     smiv2:oid 1.3.6.1.2.1.2 { alias "interfaces"; }
     smiv2:oid 1.3.6.1.2.1.2.1 { alias "ifNumber"; }

     This may in particular be useful since OBJECT-IDENTITY macros
     define constants that are used as values.

/js

-- 
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: Martin Bjorklund <[email-masked]>
Date: Sat, 09 Apr 2011 13:09:43 +0200 (CEST)

Hi,

>      define constants that are used as values.

If we want to keep the hierarchy, we can also do:

** Solution #01-02

   Declare this a non-problem since reordering these
   duplicate-assigned oids are rare.

But I wonder if solution #01-01 isn't the best after all.  There are
other potential problems with keeping the hierarchy.  Suppose you
have:

     foo OBJECT IDENTIFIER ::= { xx 1 }
     bar OBJECT IDENTIFIER ::= { foo 1 2 } 
     baz OBJECT IDENTIFIER ::= { bar 1 } 

this will presumably generate:

  container foo {
    container bar {
      container baz {
        ...
      }
    }
  }

but what if a new revision does:

     foo OBJECT IDENTIFIER ::= { xx 1 }
     goo OBJECT IDENTIFIER ::= { foo 1 }
     bar OBJECT IDENTIFIER ::= { goo 2 } 
  
This would add the goo container:

  container foo {
    container goo {
      container bar {
        container baz {
          ...
        }
      }
    }
  }

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Apr 2011 08:54:44 +0200

> This would add the goo container:

Personally, I think solution #01-01 is the way to go. Everything else
is brittle and a weak basis for an interoperable standard. Do you think
we should capture the OID tree structure as suggested in #01-01?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 12 Apr 2011 09:37:07 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> Do you think

This would be for definitions like

  ifMIBObjects OBJECT IDENTIFIER ::= { ifMIB 1 }

OBJECT-TYPE, OBJECT-IDENTITY, and NOTIFICATION-TYPE are already
handled (or should be handled) by the snmpv2:oid statement.

If we translate these assignments, I would use the existing snmpv2:oid
statement:

  smiv2:name ifMIBObjects {
    smiv2:oid "1.3.6.1.2.1.31.1";
  }

I don't mind having this as a MAY in the translation process.  I can
see that a client could use this information to display some OIDs
found in the payload in a nicer way to the user.  But I assume most
such oids come from OBJECT-TYPE or OBJECT-IDENTITY.

The reason for not doing it would be that it is sort of a slippery
slope.  In theory we could have YANG extensions for all SMIv2
constructs, but I do not think that would be very useful.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Apr 2011 09:54:36 +0200

> constructs, but I do not think that would be very useful.

I was concerned that doing some name to OID mappings inline and others
somewhere else makes things more confusing. Since the OIDs are the only
really stable identifier, I thought that doing

     smiv2:oid 1.3.6.1.2.1.2 { smiv2:alias "interfaces"; }
     smiv2:oid 1.3.6.1.2.1.2.1 { smiv2:alias "ifNumber"; }

without encoding any OIDs in generated leaf statements makes things
simpler. We could even distinguish between a fixed assigned name and
an alias, e.g.

     smiv2:oid 1.3.6.1.2.1.2 { smiv2:alias "interfaces"; }
     smiv2:oid 1.3.6.1.2.1.2.1 { smiv2:name "ifNumber"; }

All this stuff would appear at the end of a generated YANG module so
it is easy to ignore all this noise. The other alternative I think
would be to not generate smiv2:oid statements at all. A partial
coverage does not look very convincing to me.

/js