Subject: [netmod] smiv2 to yang mapping issues

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Nov 2011 10:41:32 +0100

Hi,

attached please find the issues list I am maintaining for the smiv2 to
yang mapping. You can ignore the closed issues (except for those who
want to recall history). For some issues, there is a strawman while
others are open and looking for a resolution. Lets see what we manage
to close tomorrow or during this week (sometimes solutions also evolve
around a meeting, in particular since not all implementors happen to
be at the meeting).

/js

PS: Instead of wasting some time generating slides, I am considering
    to use this plain ASCII (emacs org-mode) issue list for the
    discussion tomorrow.

-- 
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 Reid <[email-masked]>
Date: Thu, 17 Nov 2011 10:42:16 -0500

> around a meeting, in particular since not all implementors happen to

For all of the issues that have a strawman listed except for #18, I agree 
with the strawman. For #18, I like the suggestion from David Spakes to 
also include the rest of the types in Table 1 and 2 of RFC 6021.

-David Reid

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Nov 2011 04:06:17 +0100

> also include the rest of the types in Table 1 and 2 of RFC 6021.

OK. I have added Table 2 to it.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 18 Nov 2011 08:53:48 +0100 (CET)

Hi,

There is one more corner case in the type mapping algorithm.
Currently, both OCTET STRING (w/o DISPLAY-HINT) and Opaque maps to the
YANG type binary.  But these are different types on-the-wire in SNMP,
so an implementation that works off the generated YANG module does not
have enough information (e.g., the proxy use case I mentioned
earlier).  It just sees a binary and doesn't now how to encode it in
the PDU.

This can easily be solved by adding a typedef to ietf-yang-smiv2:

  typedef opaque {
    type binary;
    description
      "The opaque type represents SMIv2 Opaque values.";
    reference
      "RFC 2578 ...";
  }

and update the mapping table accordingly.

/martin

---

From: David Reid <[email-masked]>
Date: Fri, 18 Nov 2011 14:09:00 -0500

> and update the mapping table accordingly.

That seems reasonable. I had not considered the Opaque case (we discourage 
the use of Opaque).

-David Reid

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 19 Nov 2011 13:09:48 +0100

> and update the mapping table accordingly.

Makes sense. Since Opaque is officially not to be used I think it is
fine to have a matching type defined in the ietf-yang-smiv2 module.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 19 Nov 2011 14:36:23 +0100 (CET)

> That seems reasonable. I had not considered the Opaque case (we discourage 

Yes it is not normally used, but there are some std mibs that actually
use it (ALARM-MIB for example) so we should support it.

/martin

---

From: David Reid <[email-masked]>
Date: Sat, 19 Nov 2011 09:34:34 -0500

> use it (ALARM-MIB for example) so we should support it.

I agree.

-David Reid