Subject: [netmod] smi2yang-08: inline vs. outside smiv2:oid mapping

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 May 2011 10:45:43 +0200

* smi2yang-08: inline vs. outside smiv2:oid mapping [open]

  The current translation uses the smiv2:oid to denote the OID of
  constructs that are mapped to YANG. However, this leaves out any
  constructs or OID descriptors that are not mapped to YANG.

** Solution #08-01

   Do not inline OID definition but instead create a separate
   "section" at the end of a YANG module that just contains the
   OID mappings:

     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"; }

   This means less "noise" in the YANG definitions and it allows to
   capture all known OID descriptors within the YANG module. The
   downside is that in order to find out the OID for say a leaf like
   ifNumber, one has to do a lookup.

I would love to hear opinions so that this can be resolved and closed.

/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: David Spakes <[email-masked]>
Date: Thu, 5 May 2011 12:56:59 -0400 (EDT)

What was the outcome of the discussion regarding whether the converted
YANG document would have containers to mirror the branching of the MIB
tree?

-dss

On Thu, 5 May 2011, Juergen Schoenwaelder wrote:

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

-------------------------------------------------------------
 David Spakes                       email:   [email-masked]
 SNMP Research                      voice:   +1 865 573 1434
 3001 Kimberlin Heights Road          fax:   +1 865 573 9197
 Knoxville, TN  37920-9716  USA      http://www.snmp.com
-------------------------------------------------------------

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 May 2011 08:19:38 +0200

> YANG document would have containers to mirror the branching of the MIB

We dropped this idea because there is no reliable way to obtain names
for the containers: You can have multiple descriptors for a given OID
so its not clear which one to choose. Furthermore, the order of OID
value assignments can change when modules are revised and the number
of descriptors per OID can also change when MIB modules are revised.
So for these robustness reasons, we better only rely on descriptors
introduced by macro invocations.

/js

---

From: David Spakes <[email-masked]>
Date: Fri, 6 May 2011 10:18:08 -0400 (EDT)

On Fri, 6 May 2011, Juergen Schoenwaelder wrote:

> so its not clear which one to choose.

So do I understand correctly that you're talking about taking a MIB
document with branching; e.g.,

                                        +-------- statsTableA
                                        |
                      +-- statsGroupA --+
                      |                 |
          +-- stats --+                 +-------- statsTableB
          |           |
     -----+           +-- statsGroupB ----------- statsTableC
          |
          |                   +-- configGroupA -- configTableA
          |                   |
          +-- configuration --+
          |                   |
          |                   +-- configGroupB -- configTableB
          |
          +-- conformanceStatements ...

and collapsing it down to a single layer; e.g.,

          +-- statsTableA
          |
          +-- statsTableB
          |
     -----+-- statsTableC
          |
          +-- configTableA
          |
          +-- configTableB

because, for example, between two revisions of the above MIB, the
object descriptor "statsGroupA" might change to "oldStatsGroupA"?

> Furthermore,
> the order of OID value assignments can change when modules are revised

My recollection is that at one time, there was a requirement in YANG
that objects had to be in the same order between revisions.  But I think
this is no longer true.

If my recollection is correct, why would this present a problem for
smi2yang?

> and the number of descriptors per OID can also change when MIB modules
> are revised.

Would this problem not disappear if we simply allow duplications of
value for the smiv2:oid statement?  Example:

  smiv2:oid 1.3.6.1.4.1.xxxxx.1.1.1 { smiv2:alias "statsGroupA"; }
  smiv2:oid 1.3.6.1.4.1.xxxxx.1.1.1 { smiv2:alias "oldStatsGroupA"; }

Regards,

-dss

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 May 2011 16:57:22 +0200

> object descriptor "statsGroupA" might change to "oldStatsGroupA"?

You understand the collapsing correctly. The reason is that
descriptors can change and you have have multiple descriptors for the
same OID, hence it is ambiguous which one to choose.
 
> If my recollection is correct, why would this present a problem for

Since OID descriptors may be ambiguous, finding a resolution by
picking the first of the last also does not work.

Also note that YANG augmentations MUST be top-level statements, hence
capturing the nesting of augmenting tables would not work anyway.
 
>   smiv2:oid 1.3.6.1.4.1.xxxxx.1.1.1 { smiv2:alias "oldStatsGroupA"; }

Right now, the smiv2:oid statements are inline with the translated
SMIv2 macros. This means and this means not all OID descriptors are
captured. If the proposal is accepted to change the smiv2:oid
statement, I would prefer

smiv2:oid 1.3.6.1.4.1.xxxxx.1.1.1 { 
  smiv2:alias "statsGroupA";
  smiv2:alias "oldStatsGroupA";
}

and perhaps we could even distinguish hard names (assigned via macro
invocations) from weak descriptors (assigned via OID value
assignments) like this:

smiv2:oid 1.3.6.1.4.1.xxxxx.1.1.1 {
  smiv2:name "fooTable";
  smiv2:alias "bar";
}

/js