SNMP Yang fails generation

[hshorter]

The Yang included in ConfD as for SNMP Target Mib produces code which cannot be compiled due to conflicting class names and package names.

When adding SNMP-TARGET-MIB.yang, and required dependencies, the resultant package and class names clash causing the code to not compile.

[alrighttheresham]

Guys is there any plans to fix this?

[klacke]

On 02/20/2013 12:16 PM, hshorter wrote:

The Yang included in ConfD as for SNMP Target Mib produces code which cannot be compiled due to conflicting class names and package names.

---

Why would you want to use NETCONF to manipulate the Yang data models that are
a variant of an SNMP MIB.

I think that when choosing which YANG modules to manage for a device, the SNMP
tables would not be part of that.

Typically the SNMP tables have instrumentation which is already covered by
some other YANG modules.

-klacke

[alrighttheresham]

We are offering this mib with a snmp implementation on the node, we want to model in yang as well. We are not looking for an alternative solution.

Are you suggesting that there is not an underlying problem with JNC, that there is something specific about this yang file?

[klacke]

On 03/12/2013 04:48 PM, alrighttheresham wrote:

We are offering this mib with a snmp implementation on the node, we want to model in yang as well. We are not looking for an alternative solution.

Are you suggesting that there is not an underlying problem with JNC, that there is something specific about this yang file?

No, I'm not (really yet) suggesting anything. All I'm saying is that it seems a
bit odd to use NETCONF to manipulate MIBs, the failing yang files are yang
representations of MIBS.

I see three solutions,

• make the JNC adapt to the circumstances, i.e fix JNC so that it can also compile
  the yang files that stem from te MIBs

• recompile the MIBs so that the issue disappears

• Don't compile the SNMP yang files at all, this probably makes sense
  since you probably don't want to manipulate the MIBs over NETCONF
  anyway, use SNMP for that.

  It'll just be confusing for the NETCONF manager programmers to
  have the option of manipulating MIBs - over NETCONF

/klacke

[alrighttheresham]

We would prefer option 1 so that we dont find ourselves in a few weeks time in the same position with a different yang file.

Damian.

[klacke]

On 03/13/2013 08:26 AM, alrighttheresham wrote:

We would prefer option 1 so that we dont find ourselves in a few weeks time in the same position with a different yang file.

This may by, but let me provide an additional technical argument as to
to why this hopefully is a non issue today.

ConfD runs a bunch of MIBs, these are compiled (using confdc) as

file.mib -> file.yang -> file.fxs -> file.bin

The compilation of file.yang -> file.fxs is done using the confdc flag

confdc --export snmp ....

Meaning that the data, stats and config, described by file.yang is only
visible over the SNMP interface northbound.
This means that your NETCONF client will never be able to see this data, ConfD
will, when it announces its NETCONF capabilities, not include the
namespaces that originate from the SNMP MIBs.

You have your own private MIBs, and you may of course compile these
using any flags you want, but assuming that your MIBs refer to the standard
MIBs, in order for a NETCONF client to fully understand all that you'll
also have to recompile all the standard MIBs that come with ConfD so that
the --export snmp flag is not used.

$ ls $CONFD_DIR/etc/confd/snmp
IPV6-TC.fxs SNMP-NOTIFICATION-MIB.fxs SNMPv2-MIB.fxs
SNMP-COMMUNITY-MIB.fxs SNMP-TARGET-MIB.fxs SNMPv2-SMI.fxs
SNMP-FRAMEWORK-MIB.fxs SNMP-USER-BASED-SM-MIB.fxs SNMPv2-TC.fxs
SNMP-MPD-MIB.fxs SNMP-VIEW-BASED-ACM-MIB.fxs TRANSPORT-ADDRESS-MIB.fxs

/klacke

[hshorter]

In our environment there is some data which is available in both NETCONF and SNMP. For example the SNMP-NOTIFICATION-MIB, SNMPv2-MIB. This is so that 3rd parties can access this in the standard SNMP way, and also so that we can access it via NETCONF, along with the rest of the configuration.

Not being able to access via NETCONF (due to this bug) means we would have to use two protocols to access configuration on the network element.

[Emil-Tail-f]

Please test and see if 48f3057 has solved this issue.

[hshorter]

This has fixed the problem, thanks.