Subject: [netmod] smi to yang mapping status update

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Apr 2011 16:46:21 +0200

Hi,

I posted <http://tools.ietf.org/html/draft-ietf-netmod-smi-yang-00>.
This revision reflects the concensus between essentially me and Martin
regarding the open issues that I posted several days ago.

I also updated the libsmi implementation of the translation.  If you
compile the trunk sources from the SVN, the resulting smidump should
implement the translation as defined in the I-D. While I did validate
a number of generated YANG modules using pyang, there still might be
bugs. If you find one, let me know and I will see what I can do to fix
it.

It would be great if interested people can review the specification so
that we can work out any issues that might come up in a timely manner.

Thanks,

/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: Andy Bierman <[email-masked]>
Date: Fri, 15 Apr 2011 09:42:23 -0700

Hi,

I am prototyping NETCONF access to ENTITY-MIB entPhysicalTable as a test case.
I am using SVN v35413.

I used the --yang-smi-extensions option and the smi:object-identifier identity
base was missing from my ietf-yang-smiv2.yang file.  (Now updated in yuma SVN).
I could not find this file (just yang-smi.yang) in the libsmi tree.
This extension was used in imported SNMP-FRAMEWORK-MIB.yang, not ENTITY-MIB.yang.

I noticed that each top-level table gets its own YANG container and
all top-level scalars get put into a container with the MIB root name.
Is this OK with developers?  Why is this done?  It seems if there are
already N top-level objects then N+M is no worse.  IMO, the mapping would be more
consistent without the extra container.

Do we really need to have a container for the fooTable node?
Can't we just have top-level fooEntry lists?

What if we have vendor YANG modules that augment these translated modules?
YANG allows objects to be added under fooTable or fooEntry.  If fooTable is
kept then there should be an IETF guideline not to use it for anything other
than the container for list fooEntry.

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, April 13, 2011 7:46 AM
To: [email-masked]
Subject: [netmod] smi to yang mapping status update

Hi,

Thanks,

/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/>
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Apr 2011 19:30:04 +0200

> This extension was used in imported SNMP-FRAMEWORK-MIB.yang, not ENTITY-MIB.yang.

Yep, seems I am not generating the necessary import if a module uses
an identity. I will fix that.

> all top-level scalars get put into a container with the MIB root
> name.  Is this OK with developers?  Why is this done?  It seems if
> there are already N top-level objects then N+M is no worse.  IMO,
> the mapping would be more consistent without the extra container.

Consistent with what? Some modules have a rather large number of
scalars and by keeping them in a container, things do not look totally
cluttered. See for example the YANG version of the SNMPv2-MIB.

> Can't we just have top-level fooEntry lists?

This is a fair question to ask since we have to drop the *Table nodes
for augments. On the other hand, hand crafted YANG modules seem to
have a similar structure, see for example ietf-netconf-monitoring.yang.
 
> than the container for list fooEntry.

If someone add something to a translated module, he does something
wrong in the first place. See the comment libsmi generates:

/*
 * This YANG module has been generated by smidump 0.4.8:
 *
 *      smidump -f yang ENTITY-MIB
 *
 * Do not edit. Edit the source file instead!
 */

That said, if someone likes to augment something into such a module, I
think there is nothing really wrong from the YANG perspective with
adding to a *Table container.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Apr 2011 10:49:31 -0700

see inline.

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, April 15, 2011 10:30 AM
To: Andy Bierman
Cc: [email-masked]
Subject: Re: [netmod] smi to yang mapping status update

[ab: OK -- YANG does not support the ability to augment a module with
a top-level object anyway, so this container servers as an augment point
for YANG top-level leaf/leaf-list/choice additions.]

[ab: OK -- it doesn't help filtering or access control, but I guess it is
a convention by now.]

[ab: a separate YANG module can augment the generated module.
 People may need to add extensions for tool processing in build versions,
 so I do not think this comment is going to be followed.]

/*

[ab: IETF is not going to do this anyway and vendors can do whatever they want]

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Apr 2011 20:28:54 +0200

>  so I do not think this comment is going to be followed.]

[...]
 
> [ab: IETF is not going to do this anyway and vendors can do whatever 

I guess we are actually in agreement. Augmenting generated definitions
is just fine, editing a translated module is likely stupid.

/js

PS: The import bug should be fixed in r35468.